matplotlib-devel Mailing List for matplotlib (Page 5)

Eric Firing <ef...@ha...> writes:
> While in the middle of overhauling make.osx, I think it makes sense to 
> go ahead and fix the ARCH_FLAGS variable, and then use it throughout in 
> place of the hardwired ARCH_FLAGS. That will make it easier to use the 
> makefile on a range of OS X and Xcode versions. It is also simply a 
> cleaner design.
I think I fixed this - my commit is now part of
https://github.com/matplotlib/matplotlib/pull/17
> Newer versions of the libraries can also be used, although this is not 
> critical. v1.0.x still needs the 1.2 series of libpng, but master can 
> now handle
>
> ZLIBVERSION=1.2.5
> PNGVERSION=1.5.1
> FREETYPEVERSION=2.4.4
I think we should keep the changes to v1.0.x minimal - in master it
makes sense to upgrade to the newest versions. I'll make a separate pull
request for master.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,
Definitely a minor issue but I see the csd demo image a bit clipped from the
left and the top subplot mixed with the bottom one on
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.csd
Looks fine when I locally run the csd_demo.py example.
-- 
Gökhan

On Sat, Mar 5, 2011 at 10:34, Eric Firing <ef...@ha...> wrote:
> Newer versions of the libraries can also be used, although this is not
> critical. v1.0.x still needs the 1.2 series of libpng, but master can
> now handle
>
> ZLIBVERSION=1.2.5
> PNGVERSION=1.5.1
> FREETYPEVERSION=2.4.4
>
We have to make sure to check/update the urls to the new versions of these
dependencies. I'm unsure whether having variables for the versions makes
sense when the urls change over time (e.g.: the libpng currently in use in
make.osx was moved into the older-releases folder of the libpng repo,
prompting the need for this pull request in the first place).
-- Fernando

I tested your changes (up to mpl_install_std) and merged the pull request.
Upon solving the binaries issue we could probably close this pull request.
Or we could open an issue for that particular matter.
-- Fernando
On Sat, Mar 5, 2011 at 02:03, Jouni K. Seppänen <jk...@ik...> wrote:
> Jouni K. Seppänen <jk...@ik...> writes:
>
> > Fernando Garcia Bermudez <fg...@ee...> writes:
> >
> >> Fine by me as well. Maybe modify the documentation to point to
> >> mpl_install_std. How should we proceed?
> >
> > I'll make some other cleanups and create some commits that you can
> > include in your pull request.
>
> I did this now and created a pull request for you, so if you pull it
> into your branch, it should update your pull request. I realized it's
> unnecessary to have all those shell commands to export the variables,
> since make can export them for us.
>
> I tried out the other targets, but I couldn't get "binaries" to
> work. The bdist_mpkg plugin complains something about a lacking 64-bit
> wxpython. Could someone who has previously been able to create the
> installer try it on my make.osx branch? (That is,
>
> git add remote jkseppan git://github.com/jkseppan/matplotlib.git
> git fetch jkseppan
> git checkout jkseppan/make.osx
> make -f make.osx clean deps mpl_build binaries PYVERSION=2.6 PREFIX=...)
>
> This change will likely not merge cleanly into master; if people agree
> to merge this into the maintenance branch, I can do the merge into
> master.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 03/05/2011 12:03 AM, Jouni K. Seppänen wrote:
> Jouni K. Seppänen<jk...@ik...> writes:
>
>> Fernando Garcia Bermudez<fg...@ee...> writes:
>>
>>> Fine by me as well. Maybe modify the documentation to point to
>>> mpl_install_std. How should we proceed?
>>
>> I'll make some other cleanups and create some commits that you can
>> include in your pull request.
>
> I did this now and created a pull request for you, so if you pull it
> into your branch, it should update your pull request. I realized it's
> unnecessary to have all those shell commands to export the variables,
> since make can export them for us.
>
> I tried out the other targets, but I couldn't get "binaries" to
> work. The bdist_mpkg plugin complains something about a lacking 64-bit
> wxpython. Could someone who has previously been able to create the
> installer try it on my make.osx branch? (That is,
>
> git add remote jkseppan git://github.com/jkseppan/matplotlib.git
> git fetch jkseppan
> git checkout jkseppan/make.osx
> make -f make.osx clean deps mpl_build binaries PYVERSION=2.6 PREFIX=...)
>
> This change will likely not merge cleanly into master; if people agree
> to merge this into the maintenance branch, I can do the merge into
> master.
>
Jouni,
While in the middle of overhauling make.osx, I think it makes sense to 
go ahead and fix the ARCH_FLAGS variable, and then use it throughout in 
place of the hardwired ARCH_FLAGS. That will make it easier to use the 
makefile on a range of OS X and Xcode versions. It is also simply a 
cleaner design.
Newer versions of the libraries can also be used, although this is not 
critical. v1.0.x still needs the 1.2 series of libpng, but master can 
now handle
ZLIBVERSION=1.2.5
PNGVERSION=1.5.1
FREETYPEVERSION=2.4.4
Eric

Jouni K. Seppänen <jk...@ik...> writes:
> Fernando Garcia Bermudez <fg...@ee...> writes:
>
>> Fine by me as well. Maybe modify the documentation to point to
>> mpl_install_std. How should we proceed?
>
> I'll make some other cleanups and create some commits that you can
> include in your pull request.
I did this now and created a pull request for you, so if you pull it
into your branch, it should update your pull request. I realized it's
unnecessary to have all those shell commands to export the variables,
since make can export them for us.
I tried out the other targets, but I couldn't get "binaries" to
work. The bdist_mpkg plugin complains something about a lacking 64-bit
wxpython. Could someone who has previously been able to create the
installer try it on my make.osx branch? (That is, 
 git add remote jkseppan git://github.com/jkseppan/matplotlib.git
 git fetch jkseppan
 git checkout jkseppan/make.osx
 make -f make.osx clean deps mpl_build binaries PYVERSION=2.6 PREFIX=...)
This change will likely not merge cleanly into master; if people agree
to merge this into the maintenance branch, I can do the merge into
master.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Fernando Garcia Bermudez <fg...@ee...> writes:
> Fine by me as well. Maybe modify the documentation to point to
> mpl_install_std. How should we proceed?
I'll make some other cleanups and create some commits that you can
include in your pull request.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Fine by me as well. Maybe modify the documentation to point to
mpl_install_std. How should we proceed?
-- Fernando
On Fri, Mar 4, 2011 at 23:55, Eric Firing <ef...@ha...> wrote:
> On 03/04/2011 09:09 PM, Jouni K. Seppänen wrote:
> > Eric Firing<ef...@ha...> writes:
> >
> >> What is the rationale for removing the --prefix argument? It doesn't
> >> prevent one from installing in the standard location.
> >
> > The $PREFIX variables is used by make.osx for two different purposes:
> > (1) the dependencies are installed under $PREFIX and the extensions are
> > compiled to use them from there, in order to avoid version mismatches
> > with libraries in /usr, /opt, etc.; (2) the "setup.py install" command
> > is given --prefix $PREFIX as an argument so that matplotlib gets
> > installed in a non-standard location.
> >
> > I like just (1), so to install matplotlib I do "make -n mpl_install"
> > and edit the command to remove the prefix. Or, actually, edit it to be
> > "setupegg.py develop". The Makefile sets a bunch of environment
> > variables that are needed for the compilation to succeed with the
> > downloaded dependencies.
> >
> > How about putting the environment assignments in just one place and
> > creating multiple installation targets, maybe like this:
> >
> > ------------------------------------------------------------------------
> > run_cmd:
> > export PKG_CONFIG_PATH=${PKG_CONFIG_PATH} \
> > (etc) \
> > ${PYTHON} ${CMD}
> >
> > mpl_build:
> > run_cmd CMD="setup.py build"
> >
> > mpl_install:
> > run_cmd CMD="setup.py install --prefix=${PREFIX}"
> >
> > mpl_install_std:
> > run_cmd CMD="setup.py install"
> >
> > mpl_develop:
> > run_cmd CMD="setupegg.py develop"
> > ------------------------------------------------------------------------
> >
>
> That looks to me like a good solution.
>
> Eric
>
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 03/04/2011 09:09 PM, Jouni K. Seppänen wrote:
> Eric Firing<ef...@ha...> writes:
>
>> What is the rationale for removing the --prefix argument? It doesn't
>> prevent one from installing in the standard location.
>
> The $PREFIX variables is used by make.osx for two different purposes:
> (1) the dependencies are installed under $PREFIX and the extensions are
> compiled to use them from there, in order to avoid version mismatches
> with libraries in /usr, /opt, etc.; (2) the "setup.py install" command
> is given --prefix $PREFIX as an argument so that matplotlib gets
> installed in a non-standard location.
>
> I like just (1), so to install matplotlib I do "make -n mpl_install"
> and edit the command to remove the prefix. Or, actually, edit it to be
> "setupegg.py develop". The Makefile sets a bunch of environment
> variables that are needed for the compilation to succeed with the
> downloaded dependencies.
>
> How about putting the environment assignments in just one place and
> creating multiple installation targets, maybe like this:
>
> ------------------------------------------------------------------------
> run_cmd:
> export PKG_CONFIG_PATH=${PKG_CONFIG_PATH} \
> (etc) \
> ${PYTHON} ${CMD}
>
> mpl_build:
> run_cmd CMD="setup.py build"
>
> mpl_install:
> run_cmd CMD="setup.py install --prefix=${PREFIX}"
>
> mpl_install_std:
> run_cmd CMD="setup.py install"
>
> mpl_develop:
> run_cmd CMD="setupegg.py develop"
> ------------------------------------------------------------------------
>
That looks to me like a good solution.
Eric

Eric Firing <ef...@ha...> writes:
> What is the rationale for removing the --prefix argument? It doesn't 
> prevent one from installing in the standard location.
The $PREFIX variables is used by make.osx for two different purposes: 
(1) the dependencies are installed under $PREFIX and the extensions are
compiled to use them from there, in order to avoid version mismatches
with libraries in /usr, /opt, etc.; (2) the "setup.py install" command
is given --prefix $PREFIX as an argument so that matplotlib gets
installed in a non-standard location.
I like just (1), so to install matplotlib I do "make -n mpl_install"
and edit the command to remove the prefix. Or, actually, edit it to be
"setupegg.py develop". The Makefile sets a bunch of environment
variables that are needed for the compilation to succeed with the
downloaded dependencies.
How about putting the environment assignments in just one place and
creating multiple installation targets, maybe like this:
------------------------------------------------------------------------
run_cmd:
 export PKG_CONFIG_PATH=${PKG_CONFIG_PATH} \
 (etc) \
 ${PYTHON} ${CMD}
mpl_build:
 run_cmd CMD="setup.py build"
mpl_install:
 run_cmd CMD="setup.py install --prefix=${PREFIX}"
mpl_install_std:
 run_cmd CMD="setup.py install"
mpl_develop:
 run_cmd CMD="setupegg.py develop"
------------------------------------------------------------------------
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

OK, if there are no objections I will start making the appropriate changes to the code and the documentation. 
-- Michiel
On Sun Feb 27th, 2011 8:49 AM EST John Hunter wrote:
>On Sun, Feb 27, 2011 at 1:06 AM, Eric Firing <ef...@ha...> wrote:
>
>> That's a good point. Until fairly recently, interactive behavior worked
>> across backends only via ipython magic, so I think the non-interactive
>> default had a solid historical rationale. Now, however, we could
>> probably make interactive mode the startup default for interactive
>> backends without causing any problems. I agree that this would be more
>> intuitive and more familiar to people coming from matlab.
>
>Probably right -- this was a design decision made early on when I did
>not see a good way around the problem that the idle drawing across
>backends now solves. There will probably be some unintended
>consequences of changing the default, but as long as we document it
>prominently and provide a way for people to change the behavior to the
>old wan in their rc, it is probably a good idea to make this change.
>
>------------------------------------------------------------------------------
>Free Software Download: Index, Search & Analyze Logs and other IT data in 
>Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
>generated by your applications, servers and devices whether physical, virtual
>or in the cloud. Deliver compliance at lower cost and gain new business 
>insights. http://p.sf.net/sfu/splunk-dev2dev 
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 

On Fri, Mar 4, 2011 at 13:40, Eric Firing <ef...@ha...> wrote:
> On 03/04/2011 10:30 AM, Jouni K. Seppänen wrote:
> > We have an open pull request for fixing some problems in the make.osx
> > file:
> >
> > https://github.com/matplotlib/matplotlib/pull/17
> >
> > I think it's otherwise fine, but it changes the mpl_install target by
> > removing the --prefix argument. Personally I would prefer to drop the
> > --prefix, but this is originally John's file and he may have had a good
> > reason to install in a non-standard directory. Any comments?
> >
>
> I presume a user might want to be able to build and test a development
> version without replacing a production version.
>
> What is the rationale for removing the --prefix argument? It doesn't
> prevent one from installing in the standard location.
>
> Eric
>
My rationale for removing the --prefix argument was that a user might want
to compile matplotlib from source on MacOSX instead of install it from a
package (assuming such a package exists). As it stands now, the make.osx
file has some configuration at the top and then states that you shouldn't
need to configure past a point.
I've recently gone from relying on Enthought to compiling the packages I use
from source. All of the other packages (numpy/scipy, ipython, PIL, pyserial)
install by default on the site-packages relevant to the python version used
in the install. Removing the --prefix argument would bring the same
functionality to matplotlib on OSX. This default could be modified by
developers that would rather install in a test environment.
As I mention in the pull request, though, I'm still unsure if the
dependencies are compile-time or not. I've left the PREFIX intact after
installing into the production site-packages and I haven't had any issues so
far. The reason the PREFIX is needed, as README.osx explains, is because OSX
can have different types of zlib, png and freetype installed on the system.
If this change blocks the pull request from going through, though, I could
just revert that change and open up another one once we've cleared up any
doubts about what the rationale for having the --prefix in the first place
are.
-- Fernando

On 03/04/2011 10:30 AM, Jouni K. Seppänen wrote:
> We have an open pull request for fixing some problems in the make.osx
> file:
>
> https://github.com/matplotlib/matplotlib/pull/17
>
> I think it's otherwise fine, but it changes the mpl_install target by
> removing the --prefix argument. Personally I would prefer to drop the
> --prefix, but this is originally John's file and he may have had a good
> reason to install in a non-standard directory. Any comments?
>
I presume a user might want to be able to build and test a development 
version without replacing a production version.
What is the rationale for removing the --prefix argument? It doesn't 
prevent one from installing in the standard location.
Eric

We have an open pull request for fixing some problems in the make.osx
file:
https://github.com/matplotlib/matplotlib/pull/17
I think it's otherwise fine, but it changes the mpl_install target by
removing the --prefix argument. Personally I would prefer to drop the
--prefix, but this is originally John's file and he may have had a good
reason to install in a non-standard directory. Any comments?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi Ben, Hi list,
> Exactly. That's all I found too. Nothing indicates that we need to
> change anything. We are throwing away the second part of the tuple
> which has the returned filter. The only reason I see for the new
> function is so the coder can get back the filter string, which we
> don't seem to use.
It took me a while to see the problem, too. The point is: there is one parameter
missing in the new API of getSaveFileName, called selectedFilter,
which we use, and
given that it is missing, python takes it to be the next parameter, which
must be an int, and you get a TypeError. I discussed this with
Phil Thompson (the author of PyQt4) over at the PyQt4 mailing list
(see http://www.mail-archive.com/pyqt%40riverbankcomputing.com/msg23733.html)
and he told me to use getSaveFileNameAndFilter.
The other option would be to change PyQt4, dunno which is best.
Greetings
Martin
-- 
Max-Born-Institut
Max-Born-Straße 2a
12489 Berlin
+49 30 6392 1234

On Thursday, March 3, 2011, Darren Dale <dsd...@gm...> wrote:
> On Thu, Mar 3, 2011 at 10:22 AM, Benjamin Root <ben...@ou...> wrote:
>> Just for completeness, I wanted to include a link to some sort of reference
>> indicating a need to change the function. I can not find any documentation
>> that says that we need to change from getSaveFileName() to
>> getSaveFileNameAndFilter(). Can you please provide a source explaining the
>> need for this change?
>
> Try here: http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/python_v3.html#qfiledialog
>
Exactly. That's all I found too. Nothing indicates that we need to
change anything. We are throwing away the second part of the tuple
which has the returned filter. The only reason I see for the new
function is so the coder can get back the filter string, which we
don't seem to use.
Am I missing something?
Ben Root

On Thu, Mar 3, 2011 at 10:22 AM, Benjamin Root <ben...@ou...> wrote:
> Just for completeness, I wanted to include a link to some sort of reference
> indicating a need to change the function. I can not find any documentation
> that says that we need to change from getSaveFileName() to
> getSaveFileNameAndFilter(). Can you please provide a source explaining the
> need for this change?
Try here: http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/python_v3.html#qfiledialog

I noticed that this didn't exist and I never seem to want a frame anyway 
so here's a patch. I wasn't sure if anything in doc/ needed to be changed...
I don't really like the name "legend.frameon". I'd rather have 
"legend.frame" or "legend.useframe". If people would accept changing the 
name of the keyword, then this patch probably shouldn't be committed.
M

Looks like that fixed it. Thanks!
Jim
________________________________
From: Benjamin Root <ben...@ou...>
To: Jae-Joon Lee <lee...@gm...>
Cc: James Kitchen <ji...@ya...>; mat...@li...
Sent: Thu, March 3, 2011 11:40:32 AM
Subject: Re: [matplotlib-devel] Bug in Draggable Legend
On Thu, Mar 3, 2011 at 10:30 AM, Jae-Joon Lee <lee...@gm...> wrote:
I just committed a change that I believe that fixes this problem.
>
>https://github.com/matplotlib/matplotlib/commit/be420a34031c9c50813bc5be5f01a3cfb49639a1
>
>
>Regards,
>
>-JJ
>
>
>
Confirmed that it fixes the problem for me on the GTKAgg backend as well.
Ben Root
 

On Thu, Mar 3, 2011 at 10:30 AM, Jae-Joon Lee <lee...@gm...> wrote:
> I just committed a change that I believe that fixes this problem.
>
>
> https://github.com/matplotlib/matplotlib/commit/be420a34031c9c50813bc5be5f01a3cfb49639a1
>
> Regards,
>
> -JJ
>
>
Confirmed that it fixes the problem for me on the GTKAgg backend as well.
Ben Root

I just committed a change that I believe that fixes this problem.
https://github.com/matplotlib/matplotlib/commit/be420a34031c9c50813bc5be5f01a3cfb49639a1
Regards,
-JJ
On Fri, Mar 4, 2011 at 12:58 AM, James Kitchen <ji...@ya...> wrote:
> Hi all,
>
> I found a small bug in the Draggable Legend feature when you single-click on a
> legend, but don't drag it. It raises a TypeError.
>
> Here's code to reproduce. Try dragging the legend, then single-click the
> legend.
>
> #!/usr/bin/env python
> import matplotlib as mpl
> import pylab
>
> fig = pylab.figure()
> ax = fig.add_subplot(111)
> ax.plot(range(10), range(10), c='r', marker='^', picker=5, label='Ramp')
> legn = ax.legend()
> legn.draggable()
> pylab.show()
>
>
> Here's the stacktrace when I single-click:
>
> Exception in Tkinter callback
> Traceback (most recent call last):
> File "C:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__
>  return self.func(*args)
> File "C:\Python26\lib\site-packages\matplotlib\backends\backend_tkagg.py",
> line 312, in button_release_event
>  FigureCanvasBase.button_release_event(self, x, y, num, guiEvent=event)
> File "C:\Python26\lib\site-packages\matplotlib\backend_bases.py", line 1561,
> in button_release_event
>  self.callbacks.process(s, event)
> File "C:\Python26\lib\site-packages\matplotlib\cbook.py", line 262, in process
>  proxy(*args, **kwargs)
> File "C:\Python26\lib\site-packages\matplotlib\cbook.py", line 188, in
> __call__
>  return mtd(*args, **kwargs)
> File "C:\Python26\lib\site-packages\matplotlib\offsetbox.py", line 1466, in
> on_release
>  self.finalize_offset()
> File "C:\Python26\lib\site-packages\matplotlib\legend.py", line 51, in
> finalize_offset
>  loc_in_canvas = self.get_loc_in_canvas()
> File "C:\Python26\lib\site-packages\matplotlib\offsetbox.py", line 1512, in
> get_loc_in_canvas
>  ox, oy = offsetbox._offset
> TypeError: 'instancemethod' object is not iterable
>
> Jim
>
>
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi all,
I found a small bug in the Draggable Legend feature when you single-click on a 
legend, but don't drag it. It raises a TypeError.
Here's code to reproduce. Try dragging the legend, then single-click the 
legend.
#!/usr/bin/env python
import matplotlib as mpl
import pylab
fig = pylab.figure()
ax = fig.add_subplot(111)
ax.plot(range(10), range(10), c='r', marker='^', picker=5, label='Ramp')
legn = ax.legend()
legn.draggable()
pylab.show()
Here's the stacktrace when I single-click:
Exception in Tkinter callback
Traceback (most recent call last):
 File "C:\Python26\lib\lib-tk\Tkinter.py", line 1410, in __call__
 return self.func(*args)
 File "C:\Python26\lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 312, in button_release_event
 FigureCanvasBase.button_release_event(self, x, y, num, guiEvent=event)
 File "C:\Python26\lib\site-packages\matplotlib\backend_bases.py", line 1561, 
in button_release_event
 self.callbacks.process(s, event)
 File "C:\Python26\lib\site-packages\matplotlib\cbook.py", line 262, in process
 proxy(*args, **kwargs)
 File "C:\Python26\lib\site-packages\matplotlib\cbook.py", line 188, in 
__call__
 return mtd(*args, **kwargs)
 File "C:\Python26\lib\site-packages\matplotlib\offsetbox.py", line 1466, in 
on_release
 self.finalize_offset()
 File "C:\Python26\lib\site-packages\matplotlib\legend.py", line 51, in 
finalize_offset
 loc_in_canvas = self.get_loc_in_canvas()
 File "C:\Python26\lib\site-packages\matplotlib\offsetbox.py", line 1512, in 
get_loc_in_canvas
 ox, oy = offsetbox._offset
TypeError: 'instancemethod' object is not iterable
Jim
 

On Thu, Mar 3, 2011 at 3:15 AM, Martin Teichmann <lkb...@gm...>wrote:
> Hi Benjamin, Hi List,
>
> sorry for the backwards patch, here the forward one:
>
> ------------------------------------------------------------------------
> --- backend_qt4_orig.py 2011年03月02日 16:16:38.257797767 +0100
> +++ backend_qt4.py 2011年03月02日 16:17:19.526831397 +0100
> @@ -395,8 +395,9 @@
> filters.append(filter)
> filters = ';;'.join(filters)
>
> - fname = QtGui.QFileDialog.getSaveFileName(
> - self, "Choose a filename to save to", start, filters,
> selectedFilter)
> + fname, _ = QtGui.QFileDialog.getSaveFileNameAndFilter(
> + self, "Choose a filename to save to", start, filters,
> + selectedFilter)
> if fname:
> try:
> self.canvas.print_figure( unicode(fname) )
>
> ----------------------------------------------------------------------------
>
> It is done against a rather old version of matplotlib (the 0.99.3, the
> newest in kubuntu...) but the code hasn't changed since then,
> acording to github, so only the line numbers are wrong.
>
> The second patch I sent is now obsolete, as you hinted to the
> patch on github. I had followed the link on the matplotlib
> web site (http://matplotlib.sourceforge.net/) which links still to
> some subversion repository once you click onto "source code"
> Could please someone update that link to github? Or is there
> a new matplotlib website as well (google didn't find one).
>
> Greetings
>
> Martin
>
> --
> Max-Born-Institut
> Max-Born-Straße 2a
> 12489 Berlin
> +49 30 6392 1234
>
Martin,
Just for completeness, I wanted to include a link to some sort of reference
indicating a need to change the function. I can not find any documentation
that says that we need to change from getSaveFileName() to
getSaveFileNameAndFilter(). Can you please provide a source explaining the
need for this change?
Thanks,
Ben Root

On Thu, Mar 3, 2011 at 9:36 AM, Benjamin Root <ben...@ou...> wrote:
> As for the sourceforge/github confusion, we are currently in a transition
> phase. Our repository is now hosted on github, but the official website and
> trackers are still sourceforge. Sorry for any confusion there. The
> (un)official new website will be http://matplotlib.github.com.
With particular emphasis on UNofficial. I put that site up to make the
git/github developer docs available right away, and to investigate
whether we might want to host the homepage at github. There has been
no discussion of switching, let alone a decision to do so.

On Thu, Mar 3, 2011 at 3:15 AM, Martin Teichmann <lkb...@gm...>wrote:
> Hi Benjamin, Hi List,
>
> sorry for the backwards patch, here the forward one:
>
> ------------------------------------------------------------------------
> --- backend_qt4_orig.py 2011年03月02日 16:16:38.257797767 +0100
> +++ backend_qt4.py 2011年03月02日 16:17:19.526831397 +0100
> @@ -395,8 +395,9 @@
> filters.append(filter)
> filters = ';;'.join(filters)
>
> - fname = QtGui.QFileDialog.getSaveFileName(
> - self, "Choose a filename to save to", start, filters,
> selectedFilter)
> + fname, _ = QtGui.QFileDialog.getSaveFileNameAndFilter(
> + self, "Choose a filename to save to", start, filters,
> + selectedFilter)
> if fname:
> try:
> self.canvas.print_figure( unicode(fname) )
>
> ----------------------------------------------------------------------------
>
> It is done against a rather old version of matplotlib (the 0.99.3, the
> newest in kubuntu...) but the code hasn't changed since then,
> acording to github, so only the line numbers are wrong.
>
> The second patch I sent is now obsolete, as you hinted to the
> patch on github. I had followed the link on the matplotlib
> web site (http://matplotlib.sourceforge.net/) which links still to
> some subversion repository once you click onto "source code"
> Could please someone update that link to github? Or is there
> a new matplotlib website as well (google didn't find one).
>
> Greetings
>
> Martin
>
> --
> Max-Born-Institut
> Max-Born-Straße 2a
> 12489 Berlin
> +49 30 6392 1234
>
Martin,
Thank you for double-checking your patches. I will see about getting it
added into mpl today.
As for the sourceforge/github confusion, we are currently in a transition
phase. Our repository is now hosted on github, but the official website and
trackers are still sourceforge. Sorry for any confusion there. The
(un)official new website will be http://matplotlib.github.com.
Thank you for helping to make matplotlib better!
Ben Root