matplotlib-devel Mailing List for matplotlib

If we're going to use setuptools (actually already required for Python=20
2.3), I think we need to do it completely and not optionally --=20
otherwise users will start to depend on its features, which simply won't =
be there in some cases. In particular, I suspect they will make use of=20
the dependency resolution mechanisms. As I suggested on the ipython-dev=20
list this will do what you want without requiring a change to setup.py:
python -c "import setuptools; execfile('setup.py')" develop
Gael Varoquaux wrote:
> Hi,
>
> I just sent a similar e-mail to the ipython-def mailing list:
> I am not a big proponent of setuptools, but I must admit they have real=
ly
> nice feature for developpers: "python setup.py develop", which does the=
> Python equivalent of a symlink during the install so that it uses the
> source code from the check out to run.
>
> I would like to add these lines to the setup.py:
>
> """
> try:
> from setuptools import setup, find_packages
> except ImportError:
> pass
> """
>
> I cannot see waht harm this can do, and I can see the benefit: I instal=
l
> an svn checkout of MPL with:
>
> """
> sudo python setup.py develop --prefix /usr/local
> """
>
> and then maintain this check out by doing "svn up", and this even in
> windows.
>
> What do you think?
>
> Ga=EBl
>
> -----------------------------------------------------------------------=
--
> SF.Net email is sponsored by:=20
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> =20

On Dec 12, 2007 1:29 PM, Mark Bakker <ma...@gm...> wrote:
> It seems that in the latest version (0.9.1) the location of the images, such
> as home.ppm, has moved to a new directory.
> It used to be in ...\mpl-data and now it is in ...\mpl-data\images
>
> This totally breaks my code, as I use my own toolbar that uses these images,
> with a hardcoded location of the ppm files. I know, I should from now on
> distribute these ppm files with the distribution of my own program, but
> there may be others that have this problem.
>
> Not sure what the best solution is. WIll it remain in this new images
> directory from now on?
Can't say for sure, but we have no plans to move it. You may want to
follow the API_CHANGES at http://matplotlib.sf.net/API_CHANGES, which
we update whenever we do something that breaks code. This move to the
images subdirectory in the install directory was noted with:
 Moved data files into lib/matplotlib so that setuptools' develop
 mode works. Re-organized the mpl-data layout so that this source
 structure is maintained in the installation. (I.e. the 'fonts' and
 'images' sub-directories are maintained in site-packages.).
 Suggest removing site-packages/matplotlib/mpl-data and
 ~/.matplotlib/ttffont.cache before installing
Admittedly a bit cryptic.
JDH
>
> Thanks,
>
> Mark
>
> ps. Cross-posted on the users and development list
> ps2. Sorry, it sounds like I am bitching, but I really like matplotlib. Just
> needed to point out this backwards incompatibility, which may just be ugly
> coding on my part
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hello -
It seems that in the latest version (0.9.1) the location of the images, such
as home.ppm, has moved to a new directory.
It used to be in ...\mpl-data and now it is in ...\mpl-data\images
This totally breaks my code, as I use my own toolbar that uses these images,
with a hardcoded location of the ppm files. I know, I should from now on
distribute these ppm files with the distribution of my own program, but
there may be others that have this problem.
Not sure what the best solution is. WIll it remain in this new images
directory from now on?
Thanks,
Mark
ps. Cross-posted on the users and development list
ps2. Sorry, it sounds like I am bitching, but I really like matplotlib. Just
needed to point out this backwards incompatibility, which may just be ugly
coding on my part

On Wed, Dec 12, 2007 at 01:40:38PM -0500, Charlie Moad wrote:
> We added "setupegg.py" a long time ago which does exactly this. The
> line below would then be:
> python setupegg.py develop
Sorry. I am being really brain dead today.
Thanks,
Gaël

We added "setupegg.py" a long time ago which does exactly this. The
line below would then be:
python setupegg.py develop
On Dec 12, 2007 12:35 PM, Gael Varoquaux <gae...@no...> wr=
ote:
> On Wed, Dec 12, 2007 at 09:32:04AM -0800, Andrew Straw wrote:
> > If we're going to use setuptools (actually already required for Python
> > 2.3), I think we need to do it completely and not optionally --
> > otherwise users will start to depend on its features, which simply won'=
t
> > be there in some cases. In particular, I suspect they will make use of
> > the dependency resolution mechanisms. As I suggested on the ipython-dev
> > list this will do what you want without requiring a change to setup.py:
>
> > python -c "import setuptools; execfile('setup.py')" develop
>
> OK, I'll settle for this.
>
> Ga=EBl
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl=
ace
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Wed, Dec 12, 2007 at 09:32:04AM -0800, Andrew Straw wrote:
> If we're going to use setuptools (actually already required for Python 
> 2.3), I think we need to do it completely and not optionally -- 
> otherwise users will start to depend on its features, which simply won't 
> be there in some cases. In particular, I suspect they will make use of 
> the dependency resolution mechanisms. As I suggested on the ipython-dev 
> list this will do what you want without requiring a change to setup.py:
> python -c "import setuptools; execfile('setup.py')" develop
OK, I'll settle for this.
Gaël

Hi,
I just sent a similar e-mail to the ipython-def mailing list:
I am not a big proponent of setuptools, but I must admit they have really
nice feature for developpers: "python setup.py develop", which does the
Python equivalent of a symlink during the install so that it uses the
source code from the check out to run.
I would like to add these lines to the setup.py:
"""
try:
 from setuptools import setup, find_packages
except ImportError:
 pass
"""
I cannot see waht harm this can do, and I can see the benefit: I install
an svn checkout of MPL with:
"""
sudo python setup.py develop --prefix /usr/local
"""
and then maintain this check out by doing "svn up", and this even in
windows.
What do you think?
Gaël

I'm curious about the term 'threading backend'.
Recently I posted a question about how to handle slow plots, suggesting
that the backend canvas have an isabort() method so that the renderer
can stop what it is doing and post the current bitmap as it stands.
This is to support interactive operations such as panning and resizing
on large data collections.
Do you mean something similar when you say 'threading backend', and is
it already supported in IPython?
 - Paul
On Wed, Dec 12, 2007 at 01:36:01AM -0700, Fernando Perez wrote:
> Hi all,
> 
> This was posted to the ipython-dev list, but since it's specifically
> for MPL, I figured the cross-list spam would be forgiven.
> 
> In IPython SVN, I just added the ability to manually control the pylab
> threading backend choice directly from the command line. So for
> example if by default you have:
> 
> tlon[~]> ipython -pylab --nobanner
> 
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'TkAgg'
> 
> You can now do this as well:
> 
> tlon[~]> ipython -wthread -pylab --nobanner
> 
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'WXAgg'
> 
> In [2]:
> Closing threads... Done.
> tlon[~]> ipython -gthread -pylab --nobanner
> 
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'GTKAgg'
> 
> The feature is fairly simplistic: the -Xthread flags map automatically
> to the XAgg backends in MPL, with no more fine-grained choice than
> that. We can later look into allowing explicit backend selection if
> you really scream for it, but I'd rather keep this simple. This means
> that if you don't have the *Agg builds of the GUI backends, you'll
> still need to do the backend selection by hand as before (i.e. by
> modifying your mpl config file).
> 
> This has often been requested and I'd needed it myself on multiple
> occasions, so it's finally in.
> 
> Cheers,
> 
> f
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: 
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

You could add some semi-transparent text across the figure with 
something like:
gcf().text(0.1, 0.1, "Watermark", rotation=45, 
fontproperties=FontProperties(size=64), alpha=0.2)
Unfortunately, alpha-transparency on text is not supported in the Agg 
and Svg backends (more due to an oversight than it being terribly 
difficult to implement -- I can try to get this in for the 0.91.2 
release). But it does work on Pdf and Cairo. (Supporting it in Ps will 
be quite difficult).
There may also be external tools to do this *after* generating the plot 
from matplotlib, e.g.:
http://www.selonen.org/arto/netbsd/watermarks.html
Cheers,
Mike
Nils Wagner wrote:
> Hi all,
> 
> Is it possible to add a water mark to a plot ?
> 
> Nils
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: 
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Dec 12, 2007 at 01:36:01AM -0700, Fernando Perez wrote:
> You can now do this as well:
> tlon[~]> ipython -wthread -pylab --nobanner
> In [1]: matplotlib.rcParams['backend']
> Out[1]: 'WXAgg'
Hurray, mayavi and pylab can now easily live together. Thanks heaps
Fernando.
Gaël

Hi all,
This was posted to the ipython-dev list, but since it's specifically
for MPL, I figured the cross-list spam would be forgiven.
In IPython SVN, I just added the ability to manually control the pylab
threading backend choice directly from the command line. So for
example if by default you have:
tlon[~]> ipython -pylab --nobanner
In [1]: matplotlib.rcParams['backend']
Out[1]: 'TkAgg'
You can now do this as well:
tlon[~]> ipython -wthread -pylab --nobanner
In [1]: matplotlib.rcParams['backend']
Out[1]: 'WXAgg'
In [2]:
Closing threads... Done.
tlon[~]> ipython -gthread -pylab --nobanner
In [1]: matplotlib.rcParams['backend']
Out[1]: 'GTKAgg'
The feature is fairly simplistic: the -Xthread flags map automatically
to the XAgg backends in MPL, with no more fine-grained choice than
that. We can later look into allowing explicit backend selection if
you really scream for it, but I'd rather keep this simple. This means
that if you don't have the *Agg builds of the GUI backends, you'll
still need to do the backend selection by hand as before (i.e. by
modifying your mpl config file).
This has often been requested and I'd needed it myself on multiple
occasions, so it's finally in.
Cheers,
f

Hi all,
Is it possible to add a water mark to a plot ?
Nils

On Dec 11, 2007 6:51 PM, Paul Kienzle <pki...@ni...> wrote:
> I removed the mpl_connect from the scroll event to pick. I don't know
> why it was there.
>
> I tested the patch on OS X WxAgg examples/image_slice_viewer.
>
> Let me know if it is okay to post to svn, or if we are still in feature
> freeze.
As long as you are reasonably confident that this won't break existing
code, go ahead and commit it. In the next day or two, if nothing else
serious arises, I'd like to cut 0.91.2 if Charlie has time.
JDH

Hi,
I have a patch which implements the scroll wheel on wx using the
wx mouse wheel event.
Rather than a simple up/down mouse event wx uses:
 delta: intervals per click
 rotation: number of clicks
 rate: number of lines per click
I convert this to: 
 step = rotation*delta/rate
I've added the step attribute to the mpl MouseEvent in addition to the
usual up/down button (up if step >= 0, down otherwise). 
I removed the mpl_connect from the scroll event to pick. I don't know
why it was there.
I tested the patch on OS X WxAgg examples/image_slice_viewer.
Let me know if it is okay to post to svn, or if we are still in feature
freeze.
	- Paul

On Dec 11, 2007 5:42 PM, Gael Varoquaux <gae...@no...> wrote:
> On Tue, Dec 11, 2007 at 05:37:41PM -0700, Fernando Perez wrote:
> > The tconfig objects already have a very dict-like representation for
> > dumping into a text file, the .ini format. Or do you mean something
> > that's even closer to a dict, curly braces and all?
>
> No, I don't care about the curly brace. However, I don't want the
> comments. I haven't decided yet, but I am sure that I want something that
> a bit more compact than, eg "print MPLConfig()".
I see, makes sense. Hack away, I trust your judgment :)
> > > The problem is that it would break your script, so I can't send you a
> > > patch. I'd like the codebase to stay similar, so maybe we can discuss
> > > this once I have some code.
>
> > Yup, it would be good not to have mpl-tconfig, ipython-tconfig and
> > mayavi-tconfig :)
>
> Yes, lets try to keep this united. I'll probably also work on a nice
> TraitsUI view. If all three projects can use the same model, view and
> controler for the configuration file, that will make it easier to, one
> day, present a unified configuration editor for a scientific IDE (:->).
Indeed. Once we have the code in place, we'll worry about organizing
things for easy reuse.
Cheers,
f

On Tue, Dec 11, 2007 at 05:37:41PM -0700, Fernando Perez wrote:
> The tconfig objects already have a very dict-like representation for
> dumping into a text file, the .ini format. Or do you mean something
> that's even closer to a dict, curly braces and all?
No, I don't care about the curly brace. However, I don't want the
comments. I haven't decided yet, but I am sure that I want something that
a bit more compact than, eg "print MPLConfig()".
> > The problem is that it would break your script, so I can't send you a
> > patch. I'd like the codebase to stay similar, so maybe we can discuss
> > this once I have some code.
> Yup, it would be good not to have mpl-tconfig, ipython-tconfig and
> mayavi-tconfig :)
Yes, lets try to keep this united. I'll probably also work on a nice
TraitsUI view. If all three projects can use the same model, view and
controler for the configuration file, that will make it easier to, one
day, present a unified configuration editor for a scientific IDE (:->).
Gaël

On Dec 11, 2007 5:32 PM, Gael Varoquaux <gae...@no...> wrote:
> On Tue, Dec 11, 2007 at 07:14:11PM -0500, Darren Dale wrote:
> > RcParamsWrapper was created so we could get matplotlib working with the new
> > config object without a massive rewrite of the entire library. The intention
> > is to use the object-oriented interface internally, and to encourage users to
> > do the same. RcParamsWrapper simply provides the upgrade path.
>
> OK, Thanks a lot. I'll probably stick with pure objects, than, but I
> might modify the __repr__ of the object to make it more easily for the
> user to edit this interactively (ie making a representation more like to
> one you would get out of a dictionnary.
The tconfig objects already have a very dict-like representation for
dumping into a text file, the .ini format. Or do you mean something
that's even closer to a dict, curly braces and all?
> The problem is that it would break your script, so I can't send you a
> patch. I'd like the codebase to stay similar, so maybe we can discuss
> this once I have some code.
Yup, it would be good not to have mpl-tconfig, ipython-tconfig and
mayavi-tconfig :)
Cheers,
f

On Tue, Dec 11, 2007 at 07:14:11PM -0500, Darren Dale wrote:
> RcParamsWrapper was created so we could get matplotlib working with the new 
> config object without a massive rewrite of the entire library. The intention 
> is to use the object-oriented interface internally, and to encourage users to 
> do the same. RcParamsWrapper simply provides the upgrade path.
OK, Thanks a lot. I'll probably stick with pure objects, than, but I
might modify the __repr__ of the object to make it more easily for the
user to edit this interactively (ie making a representation more like to
one you would get out of a dictionnary.
The problem is that it would break your script, so I can't send you a
patch. I'd like the codebase to stay similar, so maybe we can discuss
this once I have some code.
Gaël

Sorry. Try now.
(I use psvn.el for doing svn checkins, and I mostly think it's great, but it's awfully quiet when something fails.)
Cheers,
Mike

On Tuesday 11 December 2007 7:03:57 pm Gael Varoquaux wrote:
> On Mon, Dec 10, 2007 at 08:23:57AM -0500, Darren Dale wrote:
> > Hi Gael,
> >
> > On Monday 10 December 2007 3:58:48 am Gael Varoquaux wrote:
> > > I am about to start a configuration file for mayavi's mlab, and I am
> > > strongly considering mimicking matplotlib's way of doing things.
> > >
> > > I am almost sold to Fernando's TConfig, but I am not too sure how this
> > > fits with the current rcParams dictionnary. Is there some code that I
> > > could study to see how it's done?
> >
> > Look in matplotlib/config/mplconfig.py, there is a class called
> > RcParamsWrapper that was designed to make the transition from rcParams to
> > TConfig easy for both developers and users. It should make the
> > relationship between the two pretty clear.
>
> OK, thanks.
>
> In the long run, what do you suggest I implement for mayavi2, an object
> oriented interface (pure TConfig) or an dictionnary-like interface
> (your RcParamsWrapper)?
>
> I am not too exited about your RcParamsWrapper because it is not
> generated from the configuration object, and thus the info is duplicated,
> but I guess you did this for backward compatibility reasons, and I could
> use a canonical mapping from one to the other and do this automatically.
>
> I would like to proivde an interface that feels familiar to the user,
> this is why I am looking closely at what MPL and ipython are doing.
RcParamsWrapper was created so we could get matplotlib working with the new 
config object without a massive rewrite of the entire library. The intention 
is to use the object-oriented interface internally, and to encourage users to 
do the same. RcParamsWrapper simply provides the upgrade path.
Darren

On Mon, Dec 10, 2007 at 08:23:57AM -0500, Darren Dale wrote:
> Hi Gael,
> On Monday 10 December 2007 3:58:48 am Gael Varoquaux wrote:
> > I am about to start a configuration file for mayavi's mlab, and I am
> > strongly considering mimicking matplotlib's way of doing things.
> > I am almost sold to Fernando's TConfig, but I am not too sure how this
> > fits with the current rcParams dictionnary. Is there some code that I
> > could study to see how it's done?
> Look in matplotlib/config/mplconfig.py, there is a class called 
> RcParamsWrapper that was designed to make the transition from rcParams to 
> TConfig easy for both developers and users. It should make the relationship 
> between the two pretty clear.
OK, thanks.
In the long run, what do you suggest I implement for mayavi2, an object
oriented interface (pure TConfig) or an dictionnary-like interface
(your RcParamsWrapper)?
I am not too exited about your RcParamsWrapper because it is not
generated from the configuration object, and thus the info is duplicated,
but I guess you did this for backward compatibility reasons, and I could
use a canonical mapping from one to the other and do this automatically.
I would like to proivde an interface that feels familiar to the user,
this is why I am looking closely at what MPL and ipython are doing.
Cheers,
Gaël