matplotlib-devel Mailing List for matplotlib

Hi John,
> On
> TISCALI> stdout, an error appears with WXAgg or WX backends:
> This arises from a subtle, platform dependent problem with
> where the wx backend instantiates a wxapp. Matt, I've
> reverted the wxapp instantiation to the old place. I agree
> there is no logical reason why it needs to be where it is, but
> as I indicated before, I ran into troubles trying to do it the
> logical way. This is the trouble I was referring to, but
> couldn't remember exactly what it was.
 
Hmm, OK, I guess. I think this could cause more problems like
Marcin W. saw. Then again, I was never able to reproduce these
problems, so I'm not sure how likely they are to crop up again.
I think there is a mismatch between developing libraries for
writing applications and trying to support
 from matplotlib.pylab import *
for multiple backends and platforms and expect everything to
auto-magically "Just Work" with suitably vague definitions of
Just and Work to make people think this is what they want.
So now we're back to a situation where having
 from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg
**creates** a wx.PySimpleApp?? Ick. To use a PySimpleApp, one
can either create a new one:
 import wx
 app = wx.PySimpleApp()
or access the one already squirreled away:
 app = matplotlib.backends.backend_wx.wxapp
Of course, no one does the latter because no one would expect
that importing a FigureCanvasWxAgg would have created a
wx.PySimpleApp.
From my point of view, the decisions and consequences of
interactivity should not be in backend_*, but in the code
exposing the interactivity. If pylab needs to auto-magically
create a wxPySimpleApp, do it in pylab where it won't bother
anyone else.
Thanks! 
--Matt

>>>>> "TISCALI" == TISCALI <phi...@ti...> writes:
 TISCALI> some problems:
 
 from matplotlib.matlab import *
 TISCALI> doesn't work in the samples (see examples-0 73.zip)
 TISCALI> from matplotlib.pylab import * works well.
 
 On
 TISCALI> stdout, an error appears with WXAgg or WX backends:
 
This arises from a subtle, platform dependent problem with where the
wx backend instantiates a wxapp. Matt, I've reverted the wxapp
instantiation to the old place. I agree there is no logical reason
why it needs to be where it is, but as I indicated before, I ran into
troubles trying to do it the logical way. This is the trouble I was
referring to, but couldn't remember exactly what it was.
Because I'm leaving town today and want something stable for pycon, I
went ahead and rolled out a quick bug-fix release 0.73.1 with these
changes (and Fernando, you number patch got to slip in!).
To everyone who contributes code to mpl, particularly GUI code, please
test on win32 if it is at all possible. win32 downloads account for
half of all mpl downloads, and the GUIs are not exactly the same
across platforms.
Thanks,
JDH

On Fri, 2005年03月18日 at 20:17 -0800, matplotlib-devel-
re...@li... wrote:
> On Fri, 2005年03月18日 at 20:17 -0800, matplotlib-devel-
> re...@li... wrote:
> > >>>>> "John" == John Hunter <jdh...@ac...> writes:
> > 
> > John> Just trying to build 0.73 on win32 and hot a snag on the new
> > John> _backend_gdk. My GTK win32 install, admittedly a bit out of
> > John> date, does not have
> > 
> > John> #include <gdk/gdkx.h>
> > 
> > Hmm...
> > 
> > I used the time honored "comment it out and see what happens" and was
> > able to compile and run GTK and GTKAgg examples on win32. As I
> > understand it, gdkx is an X specific extension anyway.
> > 
> > Are there problems with this approach?
> > 
> > JDH
No, it looks good, I've removed the gdkx.h line from cvs too.
When writing the extension I copied some of the code from a cairo gtk
extension which is X11 specific. But luckily the _backend_gdk function
pixbuf_get_pixels_array() is not X11 specific, so the gdkx.h include is
not even needed. Thanks for tracking it down.
Steve