matplotlib-devel Mailing List for matplotlib

I've just checked in an update to backend_wx.
This has fixes in the fillable shape classes to support the new
fillColor API.
John, I have thought carefully about your suggestion that
NavigationToolbarWx could be exported, and take only a figure in its
constructor, and I've removed the FigureControlWx stuff, and refactored
FigureWx and NavigationToolbarWx so that the toolbar can be used much as
in your GTK example. I think there is a great benefit in making
matplotlib as similar to use as possible with all backends - from both
the user experience perspective and the API.
Therefore, I have also tried to make the behaviour of the mousewheel
more similar to backend_gtk: backend_wx now performs a 'scroll' action
on whichever button the mouse is currently over.
I discovered what I believe to be a wxPython bug in button event
handling: for some reason, the mouseover does not work until at least
one button has been pressed (as for the menu!). I will look into
work-arounds, as this really is not satisfactory.
I have started to put code into place to support saving to bitmaps. This
doesn't work yet (unless you like your bitmaps in black on a black
background), but I thought it better to try to get a working backend_wx
into CVS for the changes you have made. Most of the 'known' bugs are
either fixed, or I have isolated the problem to peculiarities in
wxPython, so I'm focussing on getting some new functionality into place.
Printing first, then I'll look at using double-buffered drawing as
you've suggested.
Any backend_wx users: I'd love any good suggestions on ways around the
couple of wxPython problems I'm having.
Regards
jeremy

In the process of rationalizing the way figure size and dpi is handled
between the various backends, I had to make a number of changes to the
matplotlib backend. This will pave the way for an rc file in which
the user can set the dpi, figsize, font, etc.. properties for each
backend. But it required some changes to the Gcf and FigureManager
setup. It actually simplifies writing a new backend, but will require
some relatively painless changes to wx (GD, GTK, PS, and Template are
already updated).
In a nutshell, the proliferation of defaultDPI and defaultFigSize
throughout several parts of the code and among the various backends is
now gone. The only place where the defaults are set is in matlab.py
in the figure and savefig command. This now makes it possible to
control the figsize and dpi from the matlab interface (which before
could only be done with the OO API. 
An unfortunate side effect is that the default appearance of figures
may now be different since I have changed the defaults (different
backends used to set their own defaults, so there was no standard).
Now I use a default fig size of 8,6 (from matlab) and dpi of 72.
Jeremy - what this means for you is some more changes. Sorry to
present you with an ever changing target. I've been working pretty
hard of late clearing up a lot of lingering issues. Hopefully, we'll
stabilize soon....
- Changes to the matlab helpers API
 * _matlab_helpers.GcfBase is renamed by Gcf. Backends no longer
 need to derive from this class. Instead, they provide a factory
 function new_figure_manager(num, figsize, dpi). The destroy
 method of the GcfDerived from the backends is moved to the derived
 FigureManager. You'll want to connect the window destroy to the
 GCf.destroy method, which will forward the call to the
 FigureManager.
 * FigureManagerBase moved to backend_bases -- seemed like a better
 place for it.
 * Gcf.get_all_figwins renamed to Gcf.get_all_fig_managers
 * No default dpi or figsize arguments in the backends.
 * You'll need to change the backends.__init__ for wx to reflect the
 new API.
It was rather easy to port the existing backends and I don't think
you'll have much trouble with WX. Note there is a SCREENSIZE
parameter in the backend_gtk and backend_gd which is a constant that
determines how many pixels there are per inch on the screen. I use
this to convert from dpi (in which I assume a dpi of 72 == 1 inch) to
screen units. In my tests where I created figures with a dpi of 72,
this resulted in accurate measures of figure sizes (holding a ruler up
to the screen).
Not sure this is perfect yet, but it seems to be a step in the right
direction, and the relative sizes of the fonts to the figure appear to
be better now -- previously too large in some backends, eg, GD. There
is still a discrepancy between relative font sizes between the
backends (eg, GTK versus PS) which may have to do with the font dpi
issue (75 versus 100 dpi fonts under X11) but am not sure. In any
case, I think the CVS changes are step in the right direction
Let me know if this is clear ....
JDH