matplotlib-devel Mailing List for matplotlib

In backend_wx.py, function Copy_To_Clipboard. A call to
wx.TheClipboard.Flush()
should follow wx.TheClipboard.Close().
If not, the data put on the clipboard does not persist after the wx
application is closed.
-- 
Daniel Hyams
dh...@gm...

I mailed this to the matplotlib-users list, but it never showed, so
I'm trying this one. Apologies
if it shows up in both places :(
What I'm trying to do can be boiled down to the following: I'm trying to
place a legend precisely, using the top left corner of legend as the
"sticky" point. In other words, if I want to place the legend here:
+---------------------------------+-----------+
| | |
| | legend |
| | |
| The plot... |-----------+
| |
| |
| |
| |
| |
| |
| |
+---------------------------------+
I would have thought that I would set bbox_to_anchor = (0,0,1,1), and loc =
(1,1). I found out quickly, though, that this places the legend like this:
 +-----------+
 | |
 | legend |
 | |
+---------------------------------+-----------+
| |
| |
| |
| The plot... |
| |
| |
| |
| |
| |
| |
| |
+---------------------------------+
Which makes perfect sense from matplotlib's perspective. So all I need to
do is figure out how tall the legend is, and subtract that off the y
coordinate before passing 'loc' off to matplotlib's legend. I just can't
seem to figure out how to get that number. I tried
self.ax.get_legend().get_frame().get_height(), but that just returns 1 all
the time. I browsed all through the legend object (a live one) and just can't
find any numbers at all that look like the legend width/height, in any
coordinate
system. I hope I'm missing something obvious!
Ascii art is fun! :)
--
Daniel Hyams
dh...@gm...

I mailed this to the matplotlib-users list, but it never showed, so
I'm trying this one. Apologies
if it shows up in both places :(
What I'm trying to do can be boiled down to the following: I'm trying to
place a legend precisely, using the top left corner of legend as the
"sticky" point. In other words, if I want to place the legend here:
+---------------------------------+-----------+
| | |
| | legend |
| | |
| The plot... |-----------+
| |
| |
| |
| |
| |
| |
| |
+---------------------------------+
I would have thought that I would set bbox_to_anchor = (0,0,1,1), and loc =
(1,1). I found out quickly, though, that this places the legend like this:
 +-----------+
 | |
 | legend |
 | |
+---------------------------------+-----------+
| |
| |
| |
| The plot... |
| |
| |
| |
| |
| |
| |
| |
+---------------------------------+
Which makes perfect sense from matplotlib's perspective. So all I need to
do is figure out how tall the legend is, and subtract that off the y
coordinate before passing 'loc' off to matplotlib's legend. I just can't
seem to figure out how to get that number. I tried
self.ax.get_legend().get_frame().get_height(), but that just returns 1 all
the time. I browsed all through the legend object (a live one) and just can't
find any numbers at all that look like the legend width/height, in any
coordinate
system. I hope I'm missing something obvious!
Ascii art is fun! :)
-- 
Daniel Hyams
dh...@gm...

This line:
ARCH_FLAGS="-arch i386-arch x86_64"
should actually be
ARCH_FLAGS="-arch i386 -arch x86_64"
(notice the extra space after i386. it wouldn't build for me without this
fix.)
Uri
...................................................................................
Uri Laserson
Graduate Student, Biomedical Engineering
Harvard-MIT Division of Health Sciences and Technology
M +1 917 742 8019
las...@mi...

In reference to the configuration package idea...
I (and the users that I support) use matplotlib both as a standalone plotter
for generating lots of plots, as an interactive plotter, and as an embedded
plot in an application environment. In all of these instances we have found
the '.matplotlibrc' mechanism to be severely lacking in control of plot
formats. Users will be generating series of plots that are going to be
embedded into documents and therefore want a uniform look and feel to those
plots. Later they want to generate some plots for use on an overhead
projector (which has a much different DPI). Another time they are
interactively plotting on their workstation and still again doing all this
in an embedded form as well.
The solution we have come up with, although a little bit of a hack, is a
configuration/formatter class, where instances are used to manage the
formatting of the plots. Each instance can represent a specific set of
configurations controlling everything from font properties to background
color.
The difference here is that having global defaults is all fine and dandy,
but sometimes just setting a global default is not enough and controlling
the setting as an encapsulated entity that can be passed around and selected
at will can be quite useful.
Just my 0ドル.02
--James Evans
> On 10/28/10 12:46 PM, Russell E. Owen wrote:
> 
> > It's an interesting question. You can't call a matplotlib function to
> do
> > it because it has to happen before matplotlib is loaded. I suppose
> there
> > could be a configuration package to perform the operation.
> 
> I actually like that idea. It could even do a bit more, like have the
> matplotlib.use() function, and who knows how many others.
> 
> I've never liked the .matplotlibrc approach -- it makes great sense for
> an interactive environment, but not so much for embedding MPL in other
> apps, for all the reason's Russell has laid out.
> 
> If there was a mplconfig module that you could import first, and have
> functions in there where you could set all the defaults the way tyou
> like them, it would be easier to make self-contained MPL apps that
> didn't step on each-others toes.

On 10/28/10 11:50 AM, John Hunter wrote:
> On Thu, Oct 28, 2010 at 1:11 PM, Christopher Barker
>>> You can set these env variables within your code, before import of
>>> matplotlib via os.environment.
> The MPLCONFIGDIR tells mpl where to find the config file. It's hard
> to read the config, no matter how pythonic it is, if you don't know
> where it is.
OK -- so that does need to be set as the first part of the process.
> Once the config file (matplotlibrc) is located you can
> set the datapath with the 'datapath' parameter so you don't need
> MATPLOTLIBDATA (which is only used if datapath is not set).
So the fontcache will be put/found there? That would solve part of 
Russell's (and my) issue.
> We could use command line args, but mpl is a library and shouldn't
> really be using them... Arguably we are already doing too much in the
> way of command line args.
I agree -- command line args are not the way to go.
On 10/28/10 12:46 PM, Russell E. Owen wrote:
> It's an interesting question. You can't call a matplotlib function to do
> it because it has to happen before matplotlib is loaded. I suppose there
> could be a configuration package to perform the operation.
I actually like that idea. It could even do a bit more, like have the 
matplotlib.use() function, and who knows how many others.
I've never liked the .matplotlibrc approach -- it makes great sense for 
an interactive environment, but not so much for embedding MPL in other 
apps, for all the reason's Russell has laid out.
If there was a mplconfig module that you could import first, and have 
functions in there where you could set all the defaults the way tyou 
like them, it would be easier to make self-contained MPL apps that 
didn't step on each-others toes.
> * The font cache uses absolute paths.
perhaps that could be fixed -- how are parameters like that stored now? 
If it was an attribute of some object, it could be made a property that 
resolved the path is some nifty way. Or, if there were a mplconfig 
module, it could figure out the absolute path for the font cache at run 
time.
> * Where to put it?
>
> I had hoped to put it in the bundled application itself, so that it
> would be thrown out when the application was thrown out.
I think the official way to do it on OS-X is to put it in 
~/Library/Application Support. However, I don't now how that gets 
cleaned up -- if ever!
> I'd like to avoid generating a new MPLCONFIGDIR directory for every
> version of my application (or every version of matplotlib).
I suppose, like for any application configuration, you'd want a new 
version to check the config, and clean it out if it is for an old 
version (or, even better, update for the new version, but that's a lot 
of work)
> An alternative is to just keep using the default MPLCONFIGDIR
> (~/.matplotlib) and put up with the risk of a matplotlibrc file doing
> bad things. That's my plan for now since I know few users who bother to
> set exotic things in their matplotlibrc files, and my application
> already explicitly set the important settings.
I've gotten away with that as well, but I still don't like it!
Is is possible for MPL to read from one place, but write to another? 
Doesn't that happen already for when MPL first starts up and doesn't 
have anything?
And it sounds like the fontcache and rc file don't NEED to be in teh 
same place -- they probably shouldn't be for this type of use.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Thu, Oct 28, 2010 at 2:46 PM, Russell E. Owen <ro...@uw...> wrote:
> It's an interesting question. You can't call a matplotlib function to do
> it because it has to happen before matplotlib is loaded. I suppose there
> could be a configuration package to perform the operation.
This is basically what we already do, minus the /etc part. So we
could check some default global locations for a matplotlibrc if we
want to. Currently we
 1. check for the ENV var
 2. check the current dir for a file called matplotlibrc and use it if there
 3. check $HOME/.matplotlib/matplotlibrc
JDH

In article <4CC...@no...>,
 Christopher Barker <Chr...@no...> wrote:
> On 10/25/10 1:41 PM, Daniel Hyams wrote:
> > It doesn't really insist on it right? There are MATPLOTLIBDIR and
> > MPLCONFIGDIR environment variables.
> 
> > You can set these env variables within your code, before import of
> > matplotlib via os.environment.
> 
> I'm glad I've learned about this, and will start doing it with my 
> bundled up apps -- but that does seem pretty un-pythonic -- shouldn't it 
> be possible to set this sort of thing without resorting to that little 
> round trip through environment variables?
> 
> Not a big deal, but it feels kludgy.
> 
> -Chris
It's an interesting question. You can't call a matplotlib function to do 
it because it has to happen before matplotlib is loaded. I suppose there 
could be a configuration package to perform the operation.
Having looked into it some, I confess I am not that sold on using 
MPLCONFIGDIR in my bundled applications. Issues include:
* The font cache uses absolute paths.
Thus the cache will break if the application is moved or renamed. So 
there is no point to using MPLCONFIGDIR to avoid the problem of 
matplotlib crashing when the font cache is out of date. It cannot help!
* Where to put it?
I had hoped to put it in the bundled application itself, so that it 
would be thrown out when the application was thrown out. But matplotlib 
crashes if the directory cannot be written (pity that; it'd be nice if 
it could run without a font cache). Thus the application could not be 
run from the disk image or from an Applications directory that an admin 
had protected by making it read-only.
I'd like to avoid generating a new MPLCONFIGDIR directory for every 
version of my application (or every version of matplotlib). So it seems 
to me the only sensible choice is to have one MPLCONFIGDIR shared by all 
versions of the application. The only point I can see to doing this is 
to avoid user-written matplotlibrc files: the danger that they would 
mess up the appearance of the application or be incompatible with the 
version of matplotlib in the application.
An alternative is to just keep using the default MPLCONFIGDIR 
(~/.matplotlib) and put up with the risk of a matplotlibrc file doing 
bad things. That's my plan for now since I know few users who bother to 
set exotic things in their matplotlibrc files, and my application 
already explicitly set the important settings.
-- Russell

On Thu, Oct 28, 2010 at 1:50 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Oct 28, 2010 at 1:11 PM, Christopher Barker
> <Chr...@no...> wrote:
> > On 10/25/10 1:41 PM, Daniel Hyams wrote:
> >> It doesn't really insist on it right? There are MATPLOTLIBDIR and
> >> MPLCONFIGDIR environment variables.
> >
> >> You can set these env variables within your code, before import of
> >> matplotlib via os.environment.
> >
> > I'm glad I've learned about this, and will start doing it with my
> > bundled up apps -- but that does seem pretty un-pythonic -- shouldn't it
> > be possible to set this sort of thing without resorting to that little
> > round trip through environment variables?
> >
> > Not a big deal, but it feels kludgy.
>
> The MPLCONFIGDIR tells mpl where to find the config file. It's hard
> to read the config, no matter how pythonic it is, if you don't know
> where it is. Once the config file (matplotlibrc) is located you can
> set the datapath with the 'datapath' parameter so you don't need
> MATPLOTLIBDATA (which is only used if datapath is not set). From the
> rc file:
>
>
> # Where your matplotlib data lives if you installed to a non-default
> # location. This is where the matplotlib fonts, bitmaps, etc reside
> #datapath : /home/jdhunter/mpldata
>
>
> We could use command line args, but mpl is a library and shouldn't
> really be using them... Arguably we are already doing too much in the
> way of command line args.
>
> JDH
>
>
Isn't this a problem with any program/library? Could we go a route where
(for *nix) we check the current working directory for the file, then check
the user account's .local directory, then check the /etc directory for the
any remaining settings? Maybe for Windows use (dare I say it!) the
registry?
(Please excuse the registry idea if this completely flies in the face of
modern Windows development practices, I haven't programmed in Windows since
my days of taking AP Computer Science ten years ago).
Ben Root

On Thu, Oct 28, 2010 at 1:11 PM, Christopher Barker
<Chr...@no...> wrote:
> On 10/25/10 1:41 PM, Daniel Hyams wrote:
>> It doesn't really insist on it right? There are MATPLOTLIBDIR and
>> MPLCONFIGDIR environment variables.
>
>> You can set these env variables within your code, before import of
>> matplotlib via os.environment.
>
> I'm glad I've learned about this, and will start doing it with my
> bundled up apps -- but that does seem pretty un-pythonic -- shouldn't it
> be possible to set this sort of thing without resorting to that little
> round trip through environment variables?
>
> Not a big deal, but it feels kludgy.
The MPLCONFIGDIR tells mpl where to find the config file. It's hard
to read the config, no matter how pythonic it is, if you don't know
where it is. Once the config file (matplotlibrc) is located you can
set the datapath with the 'datapath' parameter so you don't need
MATPLOTLIBDATA (which is only used if datapath is not set). From the
rc file:
 # Where your matplotlib data lives if you installed to a non-default
 # location. This is where the matplotlib fonts, bitmaps, etc reside
 #datapath : /home/jdhunter/mpldata
We could use command line args, but mpl is a library and shouldn't
really be using them... Arguably we are already doing too much in the
way of command line args.
JDH

On 10/25/10 1:41 PM, Daniel Hyams wrote:
> It doesn't really insist on it right? There are MATPLOTLIBDIR and
> MPLCONFIGDIR environment variables.
> You can set these env variables within your code, before import of
> matplotlib via os.environment.
I'm glad I've learned about this, and will start doing it with my 
bundled up apps -- but that does seem pretty un-pythonic -- shouldn't it 
be possible to set this sort of thing without resorting to that little 
round trip through environment variables?
Not a big deal, but it feels kludgy.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Mon, Oct 25, 2010 at 9:40 AM, Michael Droettboom <md...@st...> wrote:
> On 10/23/2010 06:05 PM, David Carmean wrote:
>> As I blurted on -users, I'm thinking lately about callbacks in the
>> non-GUI portions of the libraries--mostly Artist and subclasses.
>> I'm curious if anybody else has been thinking about them?
>>
>> Ideally, I'd like to see the following:
>>
>>   All of the Artist subclasses, and anything else that might belong to
>> a Figure, would be updated to use/add cbook.CallbackRegistry callbacks
>> (weakref = good thing).
>>
>>   In addition to emulating/replacing the simplistic 'pchanged' callback
>> with a signal of that same name, there would be a signal named after each
>> setter method, and said methods fire off their eponymous signal after they
>> modify the property.
>>
>>   There should be some way to rate-limit or temporarily block individual
>> signals or callback connections.
>>
>>   The various constructors, etc, would be modified to "subscribe" to
>> the 'pchanged' signal of all children, such that even if a particular
>> object in the "middle" of a figure heirarchy does nothing with the
>> signal, a sort of a global 'pchanged' signal propagates up to the top
>> object (FigureManager, Canvas, Figure, something).
>>
>> My current Use Case for these features is in experimenting with different
>> Artist styles (Text styles/fonts, marker styles/sizes, etc), and I'm tired
>> of calling canvas.draw() all the time :)  But also, I'm working on a
>> GUI to do the same (traits UI), and want to tie both layers of the model
>> together with callbacks to speed up the experimenting.
>>
>> I've spent a few hours this weekend doing some meta-monkey-patching--
>> using __getattribute__ to decorate the setters on-the-fly to invoke
>> callbacks.process(*args) after the changes.  I have a few more quick
>> hacks to try before I'm ready to decide on a production-ready strategy.
> It's great to see someone working on this. Similar ideas have been
> thrown around since at least as long as I "joined the party" in 2007
> (search the e-mail archives for "Traits"). I like your approach because
> it should allow for a tighter integration of Traits, while at the same
> time not adding Traits as a dependency. It just might be the elusive
> middle ground that prevented us from really going forward way back when.
>
> Mike
+1 on Mike's middle-ground idea.
In case you haven't seen it, decorators are presently used to allow
Aritist.draw to make a raster mode switch for a MixedModeRenderer.
It's really a generic per-artist before/after draw signal implemented
for that single purpose. This could potentially be refactored if
there's a new signaling system in place.
-Eric

On Thu, Oct 28, 2010 at 9:55 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Oct 28, 2010 at 9:05 AM, Benjamin Root <ben...@ou...> wrote:
>
> > Just as a quick question that I would like to throw out. It isn't a bug,
> > but rather an aesthetics issue that I caused for the version 1.0 release.
> >
> > With allowing 3d plots to be made subplottable, the margins for the plot
> > area became a lot smaller than for the original method of producing 3d
> > plots. This is because of the default region for subaxes, which usually
> > matches the plotting region for a normal plot. However, 3d plots have
> been
> > explicitly setting the viewing area to take up the entire axes rather
> than
> > obeying the rcParams. With subplotting (or even creating a single plot
> > using fig.gca() ), the rcParams override the explicit setting of the plot
> > area. Therefore, 3d plots appear "squished" if created using the
> > projection='3d' approach.
> >
> > My question is this: Would it at all be feasible (or even desirable) to
> have
> > some sort of ability to specify defaults that are specific to a
> particular
> > axes type? Currently, the code for setting the parameters will grab the
> > rcparams if the figure is being newly created, or will copy the
> parameters
> > from an existing figure in the case of creating subplots in an existing
> > figure. This assumes a one-size-fits-all which 3d plots might need to be
> an
> > exception.
>
> Punting on the larger question.... others may have an opinion.
>
> If it is a feature not a bug, can you commit new baseline images for
> the buildbot and see if we can get it to go green?
>
> JDH
>
The current test failures appear to be related to changes made to
pcolormesh, and nothing to do with mplot3d. As for the mplot3d images, the
documentation images were updated, and I think I updated all of the code and
documentation. I don't think the test suite checks those, does it? Oddly
enough, I can't seem to find any test code for mplot3d (looks like another
item to add onto my todo list...).
Ben Root

On Thu, Oct 28, 2010 at 9:05 AM, Benjamin Root <ben...@ou...> wrote:
> Just as a quick question that I would like to throw out. It isn't a bug,
> but rather an aesthetics issue that I caused for the version 1.0 release.
>
> With allowing 3d plots to be made subplottable, the margins for the plot
> area became a lot smaller than for the original method of producing 3d
> plots. This is because of the default region for subaxes, which usually
> matches the plotting region for a normal plot. However, 3d plots have been
> explicitly setting the viewing area to take up the entire axes rather than
> obeying the rcParams. With subplotting (or even creating a single plot
> using fig.gca() ), the rcParams override the explicit setting of the plot
> area. Therefore, 3d plots appear "squished" if created using the
> projection='3d' approach.
>
> My question is this: Would it at all be feasible (or even desirable) to have
> some sort of ability to specify defaults that are specific to a particular
> axes type? Currently, the code for setting the parameters will grab the
> rcparams if the figure is being newly created, or will copy the parameters
> from an existing figure in the case of creating subplots in an existing
> figure. This assumes a one-size-fits-all which 3d plots might need to be an
> exception.
Punting on the larger question.... others may have an opinion.
If it is a feature not a bug, can you commit new baseline images for
the buildbot and see if we can get it to go green?
JDH

On Thu, Oct 28, 2010 at 12:44 AM, Andrew Straw <str...@as...> wrote:
> On 10/23/2010 04:59, John Hunter wrote:
> > I would be happy to do a release early next week. Is anyone aware of
> > any show stopper bugs that need to be fixed first?
>
> I think we should really get the build bot to all green again before
> doing a release. Currently, the last that happened was October 4:
> http://mpl-buildbot.code.astraw.com/waterfall
>
>
Just as a quick question that I would like to throw out. It isn't a bug,
but rather an aesthetics issue that I caused for the version 1.0 release.
With allowing 3d plots to be made subplottable, the margins for the plot
area became a lot smaller than for the original method of producing 3d
plots. This is because of the default region for subaxes, which usually
matches the plotting region for a normal plot. However, 3d plots have been
explicitly setting the viewing area to take up the entire axes rather than
obeying the rcParams. With subplotting (or even creating a single plot
using fig.gca() ), the rcParams override the explicit setting of the plot
area. Therefore, 3d plots appear "squished" if created using the
projection='3d' approach.
My question is this: Would it at all be feasible (or even desirable) to have
some sort of ability to specify defaults that are specific to a particular
axes type? Currently, the code for setting the parameters will grab the
rcparams if the figure is being newly created, or will copy the parameters
from an existing figure in the case of creating subplots in an existing
figure. This assumes a one-size-fits-all which 3d plots might need to be an
exception.
Thoughts? Comments?
Ben Root

On 10/23/2010 04:59, John Hunter wrote:
> I would be happy to do a release early next week. Is anyone aware of
> any show stopper bugs that need to be fixed first?
I think we should really get the build bot to all green again before 
doing a release. Currently, the last that happened was October 4: 
http://mpl-buildbot.code.astraw.com/waterfall

On 10/23/10 10:35 PM, jas...@cr... wrote:
> On 10/22/10 7:16 PM, Michael Droettboom wrote:
>> On 10/22/2010 05:45 PM, Russell E. Owen wrote:
>>> I'm curious when the next release of matplotlib is due.
>>>
>>> My application is suffering badly from the issue that an incorrect font
>>> cache will cause matplotlib to fail (the application mysteriously exits
>>> partway through startup until the user deletes the font cache).
>>>
>>> That problem is allegedly fixed on the trunk and I'm trying to decide
>>> how best to deal with it. Depending on the timing of 1.0.1 I can decide
>>> whether it's worth putting in my own workaround, bundling a prerelease
>>> version of matplotlib or just waiting for the official release.
>> I'm not sure what the timeframe is on 1.0.1.
>>
>> What problem with the cache are you referring to? I'm aware of a
>> problem where if some fonts are moved or removed after the cache is
>> created matplotlib will crash (and this problem is fixed in the trunk),
>> but is that really a problem in everyday practice? I'm just curious --
>> if there's another issue with the cache that I'm not aware of, I'd like
>> to fix it.
>> '
>
>
> We've been running into problems in Sage that seem to occur because font
> caches from 1.0.0 make old versions of matplotlib die. I haven't seen
> the problem myself, but several Sage developers have put in quite a bit
> of time in diagnosing the problem. In the end, I think they wrote a
> patch to do custom MPLCONFIGDIR for different versions of matplotlib in
> different versions of Sage.
>
> I'm CCing sage-devel, in case one of the sage devs that ran into
> problems wants to comment.
>
John Palmieri asked me to forward his response (below) about the 
problems Sage has been having with matplotlib and backward incompatibility:
Thanks,
Jason
==========================================================
The Sage developers have found two issues with MPLCONFIGDIR:
- First, when upgrading from version 0.99.3 to 1.0.0, the contents of
that directory seem to cause compatibility problems. That is, once
you upgrade to a version of Sage using 1.0.0, it overwrites whatever
was in that directory, and then you get errors when using an older
version of Sage which still uses 0.99.3. See
<http://trac.sagemath.org/sage_trac/ticket/9221#comment:82> for an
example of the sort of error which arises, and see
<http://trac.sagemath.org/sage_trac/ticket/6235> for our fix: in Sage,
we set MPLCONFIGDIR to different directories based on the version of
matplotlib.
- Second, the following code in matplotlib/texmanager.py can cause a
race condition when creating MPLCONFIGDIR:
 if not os.path.exists(DIR):
 os.mkdir(DIR)
In particular, when running doctests for Sage, if MPLCONFIGDIR doesn't
exist, two different doctests can try to create it at the same time,
causing a problem. (I've also heard people suggest that these sort of
race conditions can be security issues, but I don't know about the
validity of this.) See
<http://trac.sagemath.org/sage_trac/ticket/10159> for our fix: we
replace those lines by
 try:
 os.mkdir(DIR)
 except OSError, e:
 if e.errno == errno.EEXIST:
 pass
 else:
 raise
(and also add "import errno" at the beginning of the file).
I'd be happy to hear any comments you might have about these.
-- 
John Palmieri
jhp...@gm...

Hello,
recently I upgraded to matplotlib 1.0.0 which I mainly use for plotting in my (python 2.6 based) application with Qt4 GUI. Overall it works fine, but there are a few issues I experienced also with the previous version, especially with the toolbar.
When building a standalone version using py2exe, images of the toolbar are missing. I had to manually modify the .svg extensions
to .png in the _init_toolbar() function in backend_qt4.py. And for the new 'qt4_editor_options' option, no png existed yet.
Since I wanted to get rid of some toolbar functions in my standalone app, I wanted to create my own backend. But following the instructions in the backend_template.py didn't help me much. In the comments at the beginning of this file it says:
"...add 'xxx' to the switchyard in matplotlib/backends/__init__.py and 'xxx' to the backends list in the validate_backend methon in
matplotlib/__init__.py and you're off."
Unfortunately it doesn't work this way (anymore).
Is it possible to update the instructions on doing your own backend? Updating the Qt4 backend would help as well.
I know this is not the right place for feature requests, but anyway: it would be nice to have some flexibility in modifying the toolbar (which functions to add or not,etc). Now I do it the quick and dirty way: I comment out the toolbar items in the _init_toolbar() function in backend_qt4.py. However, depending on the app I'm working on, I have to comment/uncomment it...
Kind regards,
Jelmer
--Disclaimer-- 
This email and any files transmitted with it are confidential and may be privileged or otherwise protected from disclosure and are intended solely for the use of the entity / individual to whom they are addressed. If you have received this email in error or If you are not the intended recipient, please notify the sender immediately by way of telephone or email and delete this message and any files transmitted from your system. Please note that any views presented in the email are solely those of the author and do not necessarily represent those of the organization. While all care has been taken to avoid viruses the recipient is advised to check this email and attachments for presence of viruses. The organization accepts no liability on this account. 

On Mon, Oct 25, 2010 at 4:09 PM, Daniel Hyams <dh...@gm...> wrote:
> Right, I was referring specifically to MATPLOTLIBDIR ;)
>
> I was just pleased as punch to find it in the source code, documented or no
> :)
I'm guessing you mean MATPLOTLIBDATA ? And you're right, it isn't
documented (yet)...
JDH

Right, I was referring specifically to MATPLOTLIBDIR ;)
I was just pleased as punch to find it in the source code, documented or no
:)
On Mon, Oct 25, 2010 at 5:06 PM, John Hunter <jd...@gm...> wrote:
> On Mon, Oct 25, 2010 at 3:41 PM, Daniel Hyams <dh...@gm...> wrote:
>
> > It doesn't really insist on it right? There are MATPLOTLIBDIR and
> > MPLCONFIGDIR environment variables. The former is for the location of
> > mpl-data, and is not really documented well (that I could find, anyway,
> but
> > I found it in the source code), and MPLCONFIGDIR specifies where your
> > configuration files for matplotlib are. This is where your font cache
> will
> > be, as well as your matplotlibrc.
> >
> > You can set these env variables within your code, before import of
> > matplotlib via os.environment.
>
> They should be better documented, but the MPLCONFIGDIR is in the FAQ
>
>
>
> http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#matplotlib-directory-location
>
-- 
Daniel Hyams
dh...@gm...

On Mon, Oct 25, 2010 at 3:41 PM, Daniel Hyams <dh...@gm...> wrote:
> It doesn't really insist on it right? There are MATPLOTLIBDIR and
> MPLCONFIGDIR environment variables. The former is for the location of
> mpl-data, and is not really documented well (that I could find, anyway, but
> I found it in the source code), and MPLCONFIGDIR specifies where your
> configuration files for matplotlib are. This is where your font cache will
> be, as well as your matplotlibrc.
>
> You can set these env variables within your code, before import of
> matplotlib via os.environment.
They should be better documented, but the MPLCONFIGDIR is in the FAQ
http://matplotlib.sourceforge.net/faq/troubleshooting_faq.html#matplotlib-directory-location

On Mon, Oct 25, 2010 at 4:15 PM, Russell E. Owen <ro...@uw...> wrote:
> In article <4CC...@st...>,
> Michael Droettboom <md...@st...>
> wrote:
>
> > On 10/22/2010 05:45 PM, Russell E. Owen wrote:
> > > I'm curious when the next release of matplotlib is due.
> > >
> > > My application is suffering badly from the issue that an incorrect font
> > > cache will cause matplotlib to fail (the application mysteriously exits
> > > partway through startup until the user deletes the font cache).
> > >
> > > That problem is allegedly fixed on the trunk and I'm trying to decide
> > > how best to deal with it. Depending on the timing of 1.0.1 I can decide
> > > whether it's worth putting in my own workaround, bundling a prerelease
> > > version of matplotlib or just waiting for the official release.
> > I'm not sure what the timeframe is on 1.0.1.
> >
> > What problem with the cache are you referring to? I'm aware of a
> > problem where if some fonts are moved or removed after the cache is
> > created matplotlib will crash (and this problem is fixed in the trunk),
> > but is that really a problem in everyday practice? I'm just curious --
> > if there's another issue with the cache that I'm not aware of, I'd like
> > to fix it.
>
> The known problem what I am referring to. Fortunately.
>
> It has proven to be a very serious problem in practice. I bundle
> matplotlib into a Mac application and for a significant number of my
> users it crashes at startup due to problems with the matplotlib cache
> files. The fix is always the same: delete the cache.
>
> Some reasons this has happened
> - The user first runs the application from the distribution dmg file
> before copying to /Applications
> - The user installs it and runs it, but then moves or renames it for
> some reason...boom
> - The user had an older version of matplotlib installed but then deleted
> it for some reason.
>
> Fortunately the fix from the trunk will do the job.
>
> That said, it still seems risky to me that matplotlib insists on using a
> shared directory for its cache and matplotlibrc file: that there's no
> way to tell matplotlib to put that data somewhere else (e.g. inside the
> application bundle). With bundled applications it is quite likely the
> user may run multiple versions of matplotlib without even knowing it. If
> any of that data is version-dependent then this is a recipe for
> mysterious problems.
>
>
It doesn't really insist on it right? There are MATPLOTLIBDIR and
MPLCONFIGDIR environment variables. The former is for the location of
mpl-data, and is not really documented well (that I could find, anyway, but
I found it in the source code), and MPLCONFIGDIR specifies where your
configuration files for matplotlib are. This is where your font cache will
be, as well as your matplotlibrc.
You can set these env variables within your code, before import of
matplotlib via os.environment.
-- 
Daniel Hyams
dh...@gm...

In article 
<AAN...@ma...>,
 John Hunter <jd...@gm...> wrote:
> On Fri, Oct 22, 2010 at 7:16 PM, Michael Droettboom 
> <md...@st...> wrote:
> > On 10/22/2010 05:45 PM, Russell E. Owen wrote:
> >> I'm curious when the next release of matplotlib is due.
> >>
> >> My application is suffering badly from the issue that an incorrect font
> >> cache will cause matplotlib to fail (the application mysteriously exits
> >> partway through startup until the user deletes the font cache).
> >>
> >> That problem is allegedly fixed on the trunk and I'm trying to decide
> >> how best to deal with it. Depending on the timing of 1.0.1 I can decide
> >> whether it's worth putting in my own workaround, bundling a prerelease
> >> version of matplotlib or just waiting for the official release.
> > I'm not sure what the timeframe is on 1.0.1.
> 
> I would be happy to do a release early next week. Is anyone aware of
> any show stopper bugs that need to be fixed first? I had hoped to do
> it last week ahead of the ETS release, but simply did not get to it.
> 
> 
> > What problem with the cache are you referring to? I'm aware of a
> > problem where if some fonts are moved or removed after the cache is
> > created matplotlib will crash (and this problem is fixed in the trunk),
> > but is that really a problem in everyday practice? I'm just curious --
> > if there's another issue with the cache that I'm not aware of, I'd like
> > to fix it.
> 
> I used to see font cache problems when testing and/or doc building for
> a 0.99 branch release on a machine which had been running 1.0svn
> trunk. I can't replicate it now, so perhaps it is fixed (though I
> have only tried reverting the install and making plots, not doing full
> doc builds). The only commit related to the cache since the 1.0
> release that I see is
> 
> r8712 | mdboom | 2010年09月21日 16:13:25 -0400 (2010年9月21日) | 2 lines
> 
> If a font file is looked up in the cache, but that font file no longer 
> exists
> on disk, rebuild the cache.
> 
> Not sure why this would caused a failure in the case of going from 1.0
> to 0.99 ...
That's the fix I wanted.
Oddly enough, I never noticed the problem until I started bundling 1.0.0 
with my application. Then I had many reports of it. However, I also 
started bundling a strip chart widget and it's conceivable that my 
earlier simpler plots never needed the font cache.
> Russell, a good solution for you, not just for this particular
> problem, but in general, is to use MPLCONFIGDIR in your application.
> This will give you a custom location for your rc file, font cache,
> etc.... We use it on the buildbots which are running multiple
> installations of mpl to avoid clashes.
Thank you. That sounds like precisely what I wanted! I can keep my 
application self-contained. Wonderful!
-- Russell

In article <4CC...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> On 10/22/2010 05:45 PM, Russell E. Owen wrote:
> > I'm curious when the next release of matplotlib is due.
> >
> > My application is suffering badly from the issue that an incorrect font
> > cache will cause matplotlib to fail (the application mysteriously exits
> > partway through startup until the user deletes the font cache).
> >
> > That problem is allegedly fixed on the trunk and I'm trying to decide
> > how best to deal with it. Depending on the timing of 1.0.1 I can decide
> > whether it's worth putting in my own workaround, bundling a prerelease
> > version of matplotlib or just waiting for the official release.
> I'm not sure what the timeframe is on 1.0.1.
> 
> What problem with the cache are you referring to? I'm aware of a 
> problem where if some fonts are moved or removed after the cache is 
> created matplotlib will crash (and this problem is fixed in the trunk), 
> but is that really a problem in everyday practice? I'm just curious -- 
> if there's another issue with the cache that I'm not aware of, I'd like 
> to fix it.
The known problem what I am referring to. Fortunately.
It has proven to be a very serious problem in practice. I bundle 
matplotlib into a Mac application and for a significant number of my 
users it crashes at startup due to problems with the matplotlib cache 
files. The fix is always the same: delete the cache.
Some reasons this has happened
- The user first runs the application from the distribution dmg file 
before copying to /Applications
- The user installs it and runs it, but then moves or renames it for 
some reason...boom
- The user had an older version of matplotlib installed but then deleted 
it for some reason.
Fortunately the fix from the trunk will do the job.
That said, it still seems risky to me that matplotlib insists on using a 
shared directory for its cache and matplotlibrc file: that there's no 
way to tell matplotlib to put that data somewhere else (e.g. inside the 
application bundle). With bundled applications it is quite likely the 
user may run multiple versions of matplotlib without even knowing it. If 
any of that data is version-dependent then this is a recipe for 
mysterious problems.
-- Russell

 On 10/23/2010 06:05 PM, David Carmean wrote:
> As I blurted on -users, I'm thinking lately about callbacks in the
> non-GUI portions of the libraries--mostly Artist and subclasses.
> I'm curious if anybody else has been thinking about them?
>
> Ideally, I'd like to see the following:
>
> All of the Artist subclasses, and anything else that might belong to
> a Figure, would be updated to use/add cbook.CallbackRegistry callbacks
> (weakref = good thing).
>
> In addition to emulating/replacing the simplistic 'pchanged' callback
> with a signal of that same name, there would be a signal named after each
> setter method, and said methods fire off their eponymous signal after they
> modify the property.
>
> There should be some way to rate-limit or temporarily block individual
> signals or callback connections.
>
> The various constructors, etc, would be modified to "subscribe" to
> the 'pchanged' signal of all children, such that even if a particular
> object in the "middle" of a figure heirarchy does nothing with the
> signal, a sort of a global 'pchanged' signal propagates up to the top
> object (FigureManager, Canvas, Figure, something).
>
> My current Use Case for these features is in experimenting with different
> Artist styles (Text styles/fonts, marker styles/sizes, etc), and I'm tired
> of calling canvas.draw() all the time :) But also, I'm working on a
> GUI to do the same (traits UI), and want to tie both layers of the model
> together with callbacks to speed up the experimenting.
>
> I've spent a few hours this weekend doing some meta-monkey-patching--
> using __getattribute__ to decorate the setters on-the-fly to invoke
> callbacks.process(*args) after the changes. I have a few more quick
> hacks to try before I'm ready to decide on a production-ready strategy.
It's great to see someone working on this. Similar ideas have been 
thrown around since at least as long as I "joined the party" in 2007 
(search the e-mail archives for "Traits"). I like your approach because 
it should allow for a tighter integration of Traits, while at the same 
time not adding Traits as a dependency. It just might be the elusive 
middle ground that prevented us from really going forward way back when.
Mike