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.
I totally agree with everything you said. wxapp should not be
instantiated at module level in backend_wx. Unfortunately, doing it
at show level breaks win32 pylab users -- in fact it segfaults with
narry a helpful traceback to guide. I think the current situation
(wxapp at module level) is a bug and should be fixed. I simply don't
have the resources to do it myself. Someone needs or do the dirty
work of getting it organized in a way that works across platforms and
idioms (pylab versus app development). wx is still broken on OS X
(the toolbar icons look bad). I would be very thankful if you would
help with this -- it's just that we have to make sure that fixing one
thing doesn't break something else, and that changes need to be tested
on win32, linux and OS X in applications and in pylab. Admittedly,
that is a lot of work: 3 operating systems and 2 modes is 6
combinations. But this is just one of 5 GUIs matplotlib supports, so
I hope you can appreciate why I can't do it myself.
Thanks!
JDH
Hi John,
I totally agree with everything you said. wxapp should not be
instantiated at module level in backend_wx. Unfortunately,
doing it at show level breaks win32 pylab users -- in fact it
segfaults with narry a helpful traceback to guide. I think
the current situation (wxapp at module level) is a bug and
should be fixed. I simply don't have the resources to do it
myself. Someone needs or do the dirty work of getting it
organized in a way that works across platforms and idioms
(pylab versus app development).
I hope my earlier email didn't sound too grumpy!
It does seem that it may be worth thinking about long-term
design and the API and layout of backends again. That's not to
say that the current design and layout is bad, but a better
separation of the library v. interactive code could be helpful.
Then again, maybe it's good enough as is, and it's only the wx
backend that needs work. At this point, there's already enough
inertia of existing code, even subtle changes could have
significant consequences and shouldn't be done lightly.
wx is still broken on OS X (the toolbar icons look bad). I
would be very thankful if you would help with this -- it's
just that we have to make sure that fixing one thing doesn't
break something else, and that changes need to be tested on
win32, linux and OS X in applications and in pylab.
Admittedly, that is a lot of work: 3 operating systems and 2
modes is 6 combinations. But this is just one of 5 GUIs
matplotlib supports, so I hope you can appreciate why I can't
do it myself.
Hmm, I use OS X regularly, but don't use the toolbars: I'll
look into the bad icons. Personally, I don't much care for the
toolbars and don't use 'from matplotlib.pylab import *'. That
probably means I'm not looking at many use cases.
For GUIs and libraries where the result is visual, defining a
testing procedure seems difficult. Can you (anyone?) suggest a
suite of "standard tests" that might be partially automated?
--Matt
Hi John,
> wx is still broken on OS X (the toolbar icons look bad).
Hmm, I use OS X regularly, but don't use the toolbars: I'll
look into the bad icons.
The toolbar icons for both toolbars look fine to me on OS X 10.3
(matplotlib 0.73, wxPython 2.5.4.1, Apple's python2.3). Perhaps
this was fixed with wxPython 2.5.4.1 ???
--Matt