matplotlib-devel Mailing List for matplotlib

On Saturday 22 November 2003 3:48 pm, you wrote:
>
[snip]
>
> There are a couple of issues with the wx backend that I've noticed on
> my redhat linux 9 box with wxpython compiled from the src package
> wxPythonSrc-2.4.2.4. All of these are problems I was having with the
> *last* version of wx you checked in. I'm at home and can't test the
> latest code since I don't have wx installed here yet.
>
> 1) ylabel (vertical) text is not rendered properly
This works for me on both Windows and GTK ports of wxPython (actually, the 
Linux font handling is better than Windows, to my surprise). I believe that 
my Debian port is linked against GTK 1.x rather than GTK 2.x, which may make 
a difference. If you are using wxMotif, some of the font support is weaker 
than the GTK port, which may be the issue. Hard for me to tell.
> 2) initial figure window placement is still partially off screen
I can fix this with a default window position parameter, but wx is supposed to 
guess this 'intelligently' by default (and does so for me). I'll try a 
default position parameter and see how we go. If you want to see if this 
helps, pass a pos=wxPosition(x,y) default parameter to the call to 
wxFrame.__init__() frame (in FigureFrameWx constructor)
I'll try to get something into the next CVS check-in.
> 3) With a window resize, the figure doesn't seem to resize in
> correct proportions. This is something I've experimented only
> briefly so am not sure.
Haven't noticed this problem (apart from text - I'll look at this when I have 
a moment) - but I'll try a few experiments.
> 4) I've also noticed some pixel rounding error -- eg on the
> histogram demo. I have similar problems with the GTK backend and
> am not sure how to best resolve them. This tends to not be a
> problem on high res outputs where a single dot off is less
> noticeable.
> 5) Do your dashes scale with DPI? On the GTK, GD and PS backends, I
> specify dashes with points so the appearance scales with figure
> resolution. The whole issue of how things scale with DPI will
> probably arise when you get the save to hardcopy functionality
> implemented. In the eearly release of the GTK backend I did not
> handle these issues, but they inevitably become important.
I believe that dashes scale, but until I have a higher resolution output I 
won't be sure. In fact, wxPython does have the capability to generate 
user-defined dashes, but I never managed to make it work, and it's very 
poorly documented. I suspect that I may come back to this one later.
> 6) The toolbar is at the top rather than then bottom of the figure.
This was a bug in one particular CVS check-in. I believe that it has gone now, 
although I am having some trouble making a button which responds to 
mousewheel events in a cross platform way - this is curretnly the main 
toolbar issue.
> Overall things are looking very good. I may spend some time reading
> up on the WX API to see if I can lend a hand on any of these lingering
> issues since I have achieved most of my goals on the frontend side for
> 0.40. I would like to have the wx backend in a refined state because
> I suspect a lot of wx users will check out the package when we
> announce to the wx mailing list.
I'm pretty busy with other things this week, but I'll try to get preliminary 
graphics export support in place, and a couple of bugfixes (especially the 
toolbar mousewheel problem, which is important).
Regards
Jeremy

I've finally gotten around to committing the changes to backend_wx for
these API changes.
Time has been tight this week, and I haven't been able to thoroughly
regression test, but the code worked for the cases I tried.
I will be doing a more thorough set of tests over the weekend, but in the
meantime, I didn't want backend_wx to stay out of sync for any longer.
Regards
Jeremy

I've added the html docs to the CVS repository. Anyone who wants to
make additions or changes to the documentation is welcome!
Jeremy, you may want to update the WX stuff as you see fit.
The documentation is generated using a python templating engine. The
details can be found in htdocs/README.
The documentation in CVS is for the 0.40 release.
John Hunter

>>>>> "Andrew" == Andrew Brehaut <ad...@st...> writes:
 Andrew> Hi, i saw the link to matplotlib on the python url today,
 Andrew> and although i dont use matlab i do use gnuplot for alot
 Andrew> of cosc stuff i do at uni. `problem' is im getting a mac,
 Andrew> so i might be keen to help port to a cocoa backend. i cant
 Andrew> garuntee anything, but if others offer to help, i will see
 Andrew> if i can throw my support in.
Hi Andrew,
Sorry for the delay in getting back to you. I didn't see your email
until today when I was sorting through some old mail.
I don't know anything about cocoa but if you are familiar with it and
want to do a backend, by all means! There may be a couple of
alternatives, though. pygtk has been ported to os x and there is a
fink package in the unstable distribution
http://fink.sourceforge.net/pdb/section.php/gnome. If you would like
to be the crash test dummy for the gtk backend on OS X, by all means.
Please let us know what you learn.
The other alternative is to use the wx backend, which was released in
alpha version with matplotlib-0.32 and should be fairly polished in a
couple of weeks. wxpython now works on OS X -
http://www.wxpython.org/download.php#binaries. If you decide to go
this route, please report any bugs that are not listed in the KNOWN
BUGS section of the matplotlib/backends/backend_wx.py to
matplotlib-devel mailing list. As you may know, wx uses native GUI
widgets on the target platform and so should have the look and feel of
a Mac window.
You may want to consider joining the mailing lists -
http://sourceforge.net/mail/?group_id=80706.
Thanks!
John Hunter

>>>>> "Charles" == Charles R Twardy <cha...@in...> writes:
 Charles> On 2003年11月18日, John Hunter wrote: JH: JH:Good to
 Charles> hear -- I think the code is becoming much cleaner. Even
 Charles> I JH:understand the way _matlab_helpers and Gcf works
 Charles> now!
 Charles> I might need a hand there. I had a script that used to
 Charles> use the ShowOn method directly, but that isn't working
 Charles> now, and I'm not quite sure what's the right thing to do.
Is this with CVS or version 0.32? I just tested the CVS version in
interactive mode (interactive2.py) and it worked; I am not sure right
now what trouble you are having. I'd like to clear up the bug so let
me know anything you can (version info) and if possible an example
script. 
 Charles> I'm trying to maintain a figure on my own, without having
 Charles> a call to show(). I used to be able to set ShowOn to 1,
 Charles> queue draw events as needed, and update the display every
 Charles> few seconds on my own with calls to gtk_mainiteration().
As a workaround, is it possible to use the backend_gtk Figure class
directly
 from matplotlib.backends_gtk import FigureGTK
 fig = Figure(figsize=(5,4), dpi=100)
 ax = Subplot(fig, 111) # <<<- new API in CVS
Then you can do away with 'show' and 'ShowOn' altogether and use the
GTK tools directly. See the embedding_in_gtk.py and
embedding_in_gtk2.py (new in CVS) if you want to use the toolbar.
BTW, excepting the wx backend which Jeremy is still porting to the
last frontend change, CVS is now in very good shape with no known
bugs, and does a much better job of precise layout (ticklabel
positioning, tick sizes, legend placement, etc, by virtue of the new
transform system). The untrained eye may not notice a difference. So
if you are not using CVS you may want to consider it (cvs mirror may
need some time to update). I also would like as much testing as
possible before 0.40. For users, there are few significant changes
 - figure sizes and relative text sizes will appear different (as
 discussed before) but this is stabilizing. Eg, I don't anticipate
 significant changes in future releases
 - If you use the OO API directly, init Axes, Subplot with fig
 instances. If you create your own Line2D, or Rectangle, or other
 artists, you need to init them with a dpi instance, bbox, and x
 and y transformations. See the header in the transforms module. 
(for a complete list of API changes, see axes.py). I'll spell this
out in greater detail in the actual release.
JDH

On 2003年11月18日, John Hunter wrote:
JH:
JH:Good to hear -- I think the code is becoming much cleaner. Even I
JH:understand the way _matlab_helpers and Gcf works now!
I might need a hand there. I had a script that used to use the ShowOn
method directly, but that isn't working now, and I'm not quite sure what's
the right thing to do.
I'm trying to maintain a figure on my own, without having a call to
show(). I used to be able to set ShowOn to 1, queue draw events as needed,
and update the display every few seconds on my own with calls to
gtk_mainiteration().
-C
-- 
Charles R. Twardy www.csse.monash.edu.au/~ctwardy
Monash University sarbayes.org
Computer Sci. & Software Eng.
+61(3) 9905 5823 (w) 5146 (fax)

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:
 Jeremy> I'm not concerned by moving targets - the changes to date
 Jeremy> have been sensible both in improving functionality and
 Jeremy> rationalising the backend design.
Good to hear -- I think the code is becoming much cleaner. Even I
understand the way _matlab_helpers and Gcf works now!
 Jeremy> I may need to think about font size scaling separately -
 Jeremy> currently I just define the font point size, which
 Jeremy> probably is not what I should be doing. I may not have
 Jeremy> time to do this today, but will try to think about it in
 Jeremy> airport lounges ;-)
You probably will. Font size needs to scale with DPI, otherwise when
you go to a high res output the fonts look really tiny. I use
something like
 scale = self.dpi.get()/72.0
 self._font.set_size(scale*self._fontsize)
which as I indicated above is not perfect but gets close.
 Jeremy> By the way, I noticed on the users list that people are
 Jeremy> asking for Debian packages. I'm quite happy to do one, but
 Jeremy> would rather wait until things have calmed down - I'll
 Jeremy> target the 4.0 release for a .deb on the Sourceforge site.
I hope you mean 0.4 <wink>. By 4.0 we'll have already acquired The
MathWorks.
 Jeremy> We'll have to think about how the Debian package
 Jeremy> dependencies are worked out. My inclination is that we
 Jeremy> should require appropriate support for at least one
 Jeremy> backend, and suggest the others. Something like:
Required packages: python2.3-numeric, python2.3-numeric-ext, fonttools
 python2.3-gtk | libgd2-dev | libwxpython
Recommended packages: python2.3-gtk, libgd2-dev, libwxpython
Yes, I've been wondering about this but don't know enough about debian
to know how optional packages are handled. Note that neither gtk, gd,
or wx are required if all you want is PS (or Template!) output. For
the record, I'll list the dependencies by backend below. Since I am
not a debian whiz, I'll just list the actual dependencies and leave it
to the experts to sort out the debian packages that provide them
matplotlib
 Numeric
 PS backend
 (nothing extra)
 GTK backend
 GTK2
 pygtk-1.99.16 or later
 GD backend: 
 gd-2.0.15 
 gdmodule-0.42
 fonttools-2.0b1
 TTFQuery-0.2.6
 WX backend:
 wxPython-2.4.2.4
 Jeremy> Debian practice would normally provide separate packages
 Jeremy> matplotlib-doc and matplotlib-examples, so I'll try to
 Jeremy> arrange that.
 Jeremy> However, I don't really want to get into doing this until
 Jeremy> we are ready to make the next release. Debian packaging
 Jeremy> isn't especially hard, but it is rather tedious...
OK, but since we're shooting for release date of around 3 weeks from
now, it might be good to lay the groundwork, figure out how to handle
the optional dependencies, see if we can get gdmodule packed, etc....
Thanks!
John Hunter

I was unable to contact Marco awhile (months) back. I had been foolish
enough to volunteer to package, and he said he'd wait a couple of days and
then do it. After a week or so I wrote to say I wasn't going to get the
time, but my mails kept bouncing.
JV:I think that Marco Presi <zu...@de...> claims to be
JV:working on this. Maybe you can coordinate with him.
JV:See
JV:
JV: http://bugs.debian.org/206691
-- 
Charles R. Twardy www.csse.monash.edu.au/~ctwardy
Monash University sarbayes.org
Computer Sci. & Software Eng.
+61(3) 9905 5823 (w) 5146 (fax)

Hello,
On Tue, Nov 18, 2003 at 10:10:33AM -0000, Jeremy O'Donoghue wrote:
> By the way, I noticed on the users list that people are asking for Debian
> packages. I'm quite happy to do one, but would rather wait until things
> have calmed down - I'll target the 4.0 release for a .deb on the
> Sourceforge site.
> 
> We'll have to think about how the Debian package dependencies are worked
> out. My inclination is that we should require appropriate support for at
> least one backend, and suggest the others. Something like:
> 
> Required packages: python2.3-numeric, python2.3-numeric-ext, fonttools
> python2.3-gtk | libgd2-dev | libwxpython
> Recommended packages: python2.3-gtk, libgd2-dev, libwxpython
> 
> This would allow a Debian user to install matplotlib for only one backend
> (e.g. gd2 only for a webserver without X), but recommend packages to
> support other backends.
I think that Marco Presi <zu...@de...> claims to be
working on this. Maybe you can coordinate with him.
See
 http://bugs.debian.org/206691
for details.
> I can probably put simple packages for TTFQuery
> and gdmodule , which could be 'suggested'.
At http://seehuhn.de/debian/ you can find a python-ttfquery
package, which I produced for my own personal use. If
anything else in the Debian archive would use it, I probably
could upload it to the archive.
Best regards,
Jochen
-- 
http://seehuhn.de/

John Hunter said:
>
[snip]
>
> 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....
I'm not concerned by moving targets - the changes to date have been
sensible both in improving functionality and rationalising the backend
design.
Will try to commit appropriate changes today before I go off on a busines=
s
trip (back Friday, won't have CVS access before then, although I will tak=
e
a snapshot with me before I leave)
> 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
I may need to think about font size scaling separately - currently I just
define the font point size, which probably is not what I should be doing.
I may not have time to do this today, but will try to think about it in
airport lounges ;-)
By the way, I noticed on the users list that people are asking for Debian
packages. I'm quite happy to do one, but would rather wait until things
have calmed down - I'll target the 4.0 release for a .deb on the
Sourceforge site.
We'll have to think about how the Debian package dependencies are worked
out. My inclination is that we should require appropriate support for at
least one backend, and suggest the others. Something like:
Required packages: python2.3-numeric, python2.3-numeric-ext, fonttools
 python2.3-gtk | libgd2-dev | libwxpython
Recommended packages: python2.3-gtk, libgd2-dev, libwxpython
This would allow a Debian user to install matplotlib for only one backend
(e.g. gd2 only for a webserver without X), but recommend packages to
support other backends. I can probably put simple packages for TTFQuery
and gdmodule , which could be 'suggested'.
Debian practice would normally provide separate packages matplotlib-doc
and matplotlib-examples, so I'll try to arrange that.
However, I don't really want to get into doing this until we are ready to
make the next release. Debian packaging isn't especially hard, but it is
rather tedious...
Regards
Jeremy

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

I just committed several changes to CVS. Most notably, I 
changed the way edge versus face draws are done at the backend level,
as discussed earlier.
For the Renderer methods draw_arc, draw_rectangle and draw_polygon,
the signature is 
 gc, faceColor, ....
rather than 
 gc, fill, ....
faceColor is any legal matplotlib format string. To convert this to
an RGB, call backend_bases.arg_to_rgb. See GD, PS and GTK backends
for several approaches to handling edge and face calls. These (and
other minor) changes more than double the speed of pcolor in the GTK
backend and significantly reduce the size of pcolor PS output.
Other comments pertinent to the WX backend
 - backend writers should no longer need to define figure text.
 Everything is handled by Figure base class
 - artist clipOn is now a protected attribute _clipOn. Use
 set_clip_on to change it
I've pretty much fixed all the known frontend CVS bugs (scatter bug,
legend bug) and finished the ports of GD, PS and GTK backends to the
new API. Let me know if you find anything misbehaving.
John Hunter

I have incorporated log transforms into the new axes API and committed
them to CVS. There are some minor issues to hammer out, eg, ticksizes
in log transforms (which was also a problem before), but its 97.5%
working.
wx generated a nice looking log plot with log_demo.py with no changes
(cool!) but one bug was revealed
hunter:~/python/projects/matplotlib/examples> python log_demo.py -dWX
Traceback (most recent call last):
 File "/hunter/jdhunter/python/projects/matplotlib/matplotlib/backends/backend_wx.py", line 634, in _onSize
 self.bbox.set_bounds(0, 0, w, h)
NameError: global name 'w' is not defined
Cheers!
John Hunter

John Hunter wrote:
> Secondly, I am considering making a minor backend change for drawing
> 2D solids (arcs, rectangles, polygons) in the Renderer. Rather than
> calling the functions twice, once for edge and once for face, I would
> like to define them like
> Comments?
Only one comment from me: make sure to leave a way for non-convex 
polygons. It should be possible to draw, for example, a 5 pointed star 
in which the fill shouldn't extend outside the edges.

John Hunter said:
>
> The GTK and wx backends have the same problem with pixel rounding on
> pcolor. I just cured it with GTK and I bet you can do the same for
> wx. The trick is to floor the positions and ceil the scales. This
> will make it much more likely that the left edge of one rectangle will
> align with the right edge of another. Eg, for the GTK backend
>
[code snipped]
I'm sure you're right. I'll try it tomorrow.
> Secondly, I am considering making a minor backend change for drawing
> 2D solids (arcs, rectangles, polygons) in the Renderer. Rather than
> calling the functions twice, once for edge and once for face, I would
> like to define them like
>
> def draw_rectangle(self, gcEdge, x, y, width, height, gcFace=3DNone)=
:
>
> that is, the gcFace takes the place of fill. If None, don't fill,
> otherwise fill with the gc in gcFace.
>
> This will avoid 2 function calls per patch (once on the patch.py end
> and once in the backend forwarding it to the underlying renderer, and
> will enable backends, eg, postscript, to take advantage of a native
> fill commands. For PS, this will at least halve the size of pcolor
> output files, which are currently obscenely large.
This seems very sensible. The changes required in backend_wx will be
minimal, and wx has a native fill (well, a brush...), so I can take
advantage of this. Halving the size of PS output is very worthwhile, and
it'll probably double the speed of pcolor on wx.
Regards
Jeremy

I just checked in to CVS a substantial refactoring of the matplotlib
axes classed, with some smaller changes to artist.Artists and their
descendants. This won't result in any changes to the
matplotlib.matlab interface, and only minor changes to the API for
embedding matplotlib in applications (eg, a one line change to the
embedding_gtk.py example).
But it will make it easier to support, develop and maintain the
library internally. For example, the legend command works better now,
producing a better layout, and the tick and label placement works
better.
Pretty much everything is working with known examples *except*
 1) log scaling
 2) GD backend
and these two will come along in a day or two.
So please exercise caution before checking out CVS; if you do check it
out, let me know about any bugs you find (it usually takes a while for
the mirrors to sync)
See axes.py for a summary of changes.
Thanks!
John Hunter 

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:
 Jeremy> I think this will also benefit the 'measurement' class. I
 Jeremy> saw that there were the beginnings of some code in
 Jeremy> backend_gtk (and this is a Matlab feature I've always
 Jeremy> loved), so I started to think about it... and quickly
 Jeremy> decided against it!
Yes, I've used this in a GTK app which controlled an EMG machine. The
new transform architecture is pretty clean, in my biased opinion
<wink> and should make these kinds of things easier. The xaxis and
yaxis instances store two Transform instances 1) relative->display and
2) data->display. Since transforms know their inverse, it is easy to
get from display->data. You can do it like:
 itransx = axes.xaxis.transData.inverse() # display->data transform
 itransx = axes.yaxis.transData.inverse()
 x, y = event.x, event.y # mouse location in display coords
 x = itransx.positions(x) # data coords
 y = itransy.positions(y)
 
Much cleaner than before! Although I should finish the log stuff
before I get too proud of myself.
 Jeremy> I think it's wise to get the changes into CVS quite
 Jeremy> soon. It sounds as though you have most things sorted out,
 Jeremy> and I can make changes fairly quickly.
Will do, I've finished changing over the GTK backend and PS backend.
You can diff the GTK backend against the earlier version to see where
most of the changes are required. Also, see the API changes listed at
the header of axes.py.
 In a nutshell
 - Init all Artists with a dpi instance variable, a Bound2D instance
 variable. In the derived Figure class, this will need to be done
 for the figurePatch and AxisText instances you create. 
 - remove any gc clip code you have in the figure or AxisText class
 - replace any transformations you do in AxisText draw with the
 transx and transy attribute calls
 - make sure you get the get_window_extent just right by activating
 the bbox_artist calls in Axis._draw. Run an example with if 0:
 replaced by if 1: with the gtk backend to see what I mean
 - Note that all of the viewlim and transform variables are passed
 by reference in axes.py, so all transforms are updated
 automagically with a change to the viewlim with no functional
 calls. See transforms.py. Likewise for DPI. It is now a mutable
 instance variable so you should update it with
 self.dpi.set(newval)
 rather than
 self.dpi = DPI(newval) # this would break the reference
 self.dpi = newval # this is illegal, dpi is a DPI instance
 - lose all the set_size stuff and call axes.resize() in response to
 figure resize events, *after updating the figure bbox*. Since
 the axes has a ref to the figure now, you don't need to pass any
 information to the axes after you have updated the box. Note as
 above, in the figure class do
 self.bbox.set_bounds(l,b,w,h) # update existing instance
 
 rather than
 self.bbox = Bound2D(l,b,w,h) # breaks the references
 
 Jeremy> It would probably be polite to let the development list
 Jeremy> (and maybe even the users list) know when you've checked
 Jeremy> in potentially destabilising changes, but the refactoring
 Jeremy> sounds as though it will substantially simplify the
 Jeremy> backend implementations.
Will do.
 Jeremy> I've incorporated the current CVS verion of matplotlib
 Jeremy> into my throughput analysis application, and I'm already
 Jeremy> getting good feedback from colleagues on the improved
 Jeremy> charting. I can also confirm that I'm pretty impressed by
 Jeremy> the data clipping - I'm seeing very good performance with
 Jeremy> fairly large (~1MB x 3 axes data sets). I could probably
 Jeremy> supply a screenshot in a couple of weeks for the website,
 Jeremy> if you're interested.
I'd love a screenshot. As for 3x1MB, you can probably go
substantially beyond that if you have a decent PC. I routinely plot
15MB files with good performance. 100MB gets a bit pokey on my
machine. Numeric is really amazingly fast. But in future versions,
I'd like to support memory mapped files to support really large data
sets.
 Jeremy> I'll also try to write wx versions of some of the demos
 Jeremy> which I've marked as N/A (because they depend on GTK in
 Jeremy> some way - this will help people to get going with
 Jeremy> embedding in a wx App (and will give me something to post
 Jeremy> to the wxPyWiki at a later date).
 Jeremy> By the way, I've notice that Sourceforge takes a couple of
 Jeremy> days to update the mailing lists - rather longer than I
 Jeremy> expected.
Yep, sourceforge has been pretty flaky.
CVS update to follow.
JDH

The GTK and wx backends have the same problem with pixel rounding on
pcolor. I just cured it with GTK and I bet you can do the same for
wx. The trick is to floor the positions and ceil the scales. This
will make it much more likely that the left edge of one rectangle will
align with the right edge of another. Eg, for the GTK backend
 def draw_rectangle(self, gc, filled, x, y, width, height):
 """
 Draw a rectangle at lower left x,y with width and height
 If filled=True, fill the rectangle with the gc foreground
 gc is a GraphicsContext instance
 """
 self.gdkDrawable.draw_rectangle(
 gc.gdkGC, filled, int(x), self.height-int(y+height),
 int(math.ceil(width)), int(math.ceil(height)))
This worked great on my test code.
Secondly, I am considering making a minor backend change for drawing
2D solids (arcs, rectangles, polygons) in the Renderer. Rather than
calling the functions twice, once for edge and once for face, I would
like to define them like
 def draw_rectangle(self, gcEdge, x, y, width, height, gcFace=None):
that is, the gcFace takes the place of fill. If None, don't fill,
otherwise fill with the gc in gcFace.
This will avoid 2 function calls per patch (once on the patch.py end
and once in the backend forwarding it to the underlying renderer, and
will enable backends, eg, postscript, to take advantage of a native
fill commands. For PS, this will at least halve the size of pcolor
output files, which are currently obscenely large.
Comments?
JDH

Hi John,
I've attached a copy of the updated backend_wx.py. Time permitting, I'll
try to verify which of the examples work correctly under my Linux install=
.
John Hunter said:
>>>>>> "Jeremy" =3D=3D Jeremy O'Donoghue <je...@o-...> writes:
>
> Jeremy> I have just made a further update to backend_wx. Details
> Jeremy> below.
>
> Hi Jeremy,
>
> Thanks for the detailed update and all the progress. I have been
> working hard on refactoring the frontend, and have made substantial
> changes to the axes classes. This was motivated in part by your
> comment that the transform system was not clear to you, and I've
> always thought it was something of a hack.
It's good to hear this. I really was starting to dispair of getting the X
axis label in the correct place: each time I thought I had a change, it
broke something else.
> So I've cleared that up - artists now carry around their own
> transforms which contain references to the viewlim and displaylim, so
> the transforms are automagically updated in response to window resize
> events, etc.... Also, all the artists can now have their coordinates
> in arbitrary data coords (as before), or relative (0,1) axes or figure
> coords. This makes it much more natural to specify, for example, tick
> locations, figure legends, etc... All of the artists now handle their
> own transforms and clipping and the backend writer doesn't need to
> know anything about it.
I think this will also benefit the 'measurement' class. I saw that there
were the beginnings of some code in backend_gtk (and this is a Matlab
feature I've always loved), so I started to think about it... and quickly
decided against it!
[snip]
> The reason I bring this up is I am wondering if you would like me to
> check this into CVS and let you integrate the changes now, or wait
> until I am completely finished. Some of the features will probably
> help you -- like getting the xlabel located properly, since axis text
> locations are now done in axes coords. All you have to do is make
> sure your axes text instance can return its window extent l,b,w,h in
> window coords and the front in will take care of the rest. I have a
> helper function to draw a bbox around artists to help show whether the
> bbox you return is correct.
I think it's wise to get the changes into CVS quite soon. It sounds as
though you have most things sorted out, and I can make changes fairly
quickly.
It would probably be polite to let the development list (and maybe even
the users list) know when you've checked in potentially destabilising
changes, but the refactoring sounds as though it will substantially
simplify the backend implementations.
I'll leave implementation of printing until after the changes have
stailised a bit, as they will probably help me in this area as well.
I've incorporated the current CVS verion of matplotlib into my throughput
analysis application, and I'm already getting good feedback from
colleagues on the improved charting. I can also confirm that I'm pretty
impressed by the data clipping - I'm seeing very good performance with
fairly large (~1MB x 3 axes data sets). I could probably supply a
screenshot in a couple of weeks for the website, if you're interested.
I'll also try to write wx versions of some of the demos which I've marked
as N/A (because they depend on GTK in some way - this will help people to
get going with embedding in a wx App (and will give me something to post
to the wxPyWiki at a later date).
By the way, I've notice that Sourceforge takes a couple of days to update
the mailing lists - rather longer than I expected.
Regards
Jeremy

>>>>> "Jeremy" == Jeremy O'Donoghue <je...@o-...> writes:
 Jeremy> I have just made a further update to backend_wx. Details
 Jeremy> below.
Hi Jeremy,
Thanks for the detailed update and all the progress. I have been
working hard on refactoring the frontend, and have made substantial
changes to the axes classes. This was motivated in part by your
comment that the transform system was not clear to you, and I've
always thought it was something of a hack. 
So I've cleared that up - artists now carry around their own
transforms which contain references to the viewlim and displaylim, so
the transforms are automagically updated in response to window resize
events, etc.... Also, all the artists can now have their coordinates
in arbitrary data coords (as before), or relative (0,1) axes or figure
coords. This makes it much more natural to specify, for example, tick
locations, figure legends, etc... All of the artists now handle their
own transforms and clipping and the backend writer doesn't need to
know anything about it.
I also factored all tick, ticklabel, and gridline functionality into a
a Tick class, and legend capability into a Legend class which works
better and has more options than before.
I have made a number of API changes that will not have any effect on
the matlab interface and only a minor effect on backend
implementations (none currently on the Renderer or GraphicsContext,
but minor changes in the derived Figure class. I have made notes on
all the API changes so I don't think you will have much difficulty
implementing them. All of the examples except for log scaling work
perfectly, and the base code is much cleaner and I think more
readable.
The reason I bring this up is I am wondering if you would like me to
check this into CVS and let you integrate the changes now, or wait
until I am completely finished. Some of the features will probably
help you -- like getting the xlabel located properly, since axis text
locations are now done in axes coords. All you have to do is make
sure your axes text instance can return its window extent l,b,w,h in
window coords and the front in will take care of the rest. I have a
helper function to draw a bbox around artists to help show whether the
bbox you return is correct.
Alternatively, I can keep these changes local until they are done and
you are ready to incorporate them.
I can't check out backend_wx.py yet because my CVS mirror is behind.
Perhaps you can just email me a copy.
JDH

I have just made a further update to backend_wx.
Details below.
regards
Jeremy
Changes are:
- Support for mousewheel: using the mousewheel anywhere on the
 toolbar or client area will perform the last selected interactive
 function (if any)
- Added a status bar to interactive figure. This gives tooltips as
 mouse travels over buttons, and indicates the last selected
 interactive function: this is the function which will be called
 when the mousewheel is used.
- Fixed bug where legend was not displayed
- Fixed bug no clipping performed on text labels
- Fixed bug script session does not exit cleanly on Windows 2000
- Fixed bug vertical text renders incorrectly. Actually this is not
 a bug, but a wxPython feature: if you select a non-TrueType font
 on Windows platform, display of rotated text is not possible. Fix
 (for demo programs) was to trap the handle 'courier' and make it
 map to a TrueType font. Longer term fix is to make sure that you
 use a TrueType font.
Not yet implemented:
- Printing
- Measure between two points
Known bugs / issues:
- Under Windows 2000, the Figure window is larger than the figure
 (OK on Linux, however)
- pcolor almost works! See pcolor_demo. But there appears to be a
 rounding error in the locations of the patches, shich gives a
 banded appearance to the pcolor
- xlabel location is incorrect. Actually, I'm having a great deal
 of trouble tracking this one down.
- Display of axes menu under wxGTK is ugly (this is more of a wxGTK
 implementation issue!)
- No axes selected when menu initially called - have to press the
 menu key to 'select' an axis. Behaviour here could be improved.
- Using Y axis zoom causes vertical axis text to become misplaced.
- Vertical text renders incorrectly if you use a non TrueType font
 on Windows. This is a known wxPython issue.
The following example programs work for me (subject to caveats above):
---------------------------------------------------------------
 | Windows 2000 | Linux |
 | wxPython 2.3.3 | wxPython 2.4.2.4 |
--------------------------------------------------------------|
- arctest.py | OK |
- axes_demo.py | OK (1) |
- color_demo.py | OK |
- dynamic_demo.py | N/A (2) |
- embedding_in_gtk.py | N/A (2) |
- errorbar_demo.py | OK |
- figtext.py | OK |
- histogram_demo.py | OK |
- interactive.py | N/A (2) |
- interactive2.py | N/A (2) |
- legend_demo.py | OK |
- line_styles.py | OK |
- log_demo.py | OK |
- logo.py | FAIL (3) |
- mpl_with_glade.py | N/A (2) |
- mri_demo.py | FAIL (4) |
- mri_demo_with_eeg.py | FAIL (4) |
- multiple_figs_demo.py | OK |
- pcolor_demo.py | OK |
- scatter_demo.py | OK |
- simple_plot.py | OK |
- stock_demo.py | OK |
- subplot_demo.py | OK |
- system_monitor.py | N/A (2) |
- text_handles.py | OK |
- text_themes.py | OK |
- vline_demo.py | OK |
---------------------------------------------------------------
(1) - Do not see data in top right axis until zoom approx x5
 (probably a bug)
(2) - Script uses GTK-specific features - cannot not run,
 but wxPython equivalent should be written.
(3) - Script fails with: No such file or directory:
 'data/membrane.dat' - get the data file!
 (probably not a bug)
(4) - Script fails with: ValueError: string size must be a multiple
 of element size. (probably not a bug)

I have just committed an update to backend_wx.
New features:
- Preliminary support for interactive pan and zoom. This
 does not yet support use of mouse wheel, but buttons
 seem to work.
Bug fixes:
- Interactive sessions no longer require a PyCrust
 console (fixed by JDH)
- Location for pixmaps now defined by Distutils (fixed
 by JDH)
- Circle centres now correctly located.
- Axes background colours now respected
- Coloured text labels now functional
- Misc changes of variable names to conform to matplotlib
 conventions
Known bugs:
- Scripts (and interactive sessions) do not exit cleanly
- Vertical text renders incorrectly (e.g. ylabels)
- pcolor almost works (rounding error)
- xlabel location incorrect
- No clipping on text labels
There are probably many other bugs - please inform via this list.
Thanks
Jeremy

>>>>> Jeremy writes:
 Jeremy> My Sourceforge user name is jodonoghue
OK, I've added you to the developers section on CVS. I just merged
some changes to CVS. You should see if you can commit some changes
after you check out the latest. 
 Jeremy> CVS, like most SCM tools, doesn't help you quite this
 Jeremy> much. All it really does is to keep a diff every time a
 Jeremy> new file is committed, so it is quite possible that if you
 Jeremy> make a change to a file, and then I check in a new change
 Jeremy> without an update, HEAD would 'loose' your update
 Jeremy> (although it would be easy using a CS diff to determine
 Jeremy> the 'lost' code.
I think it will be a good learning experience for me since I've never
worked on a CVS project with multiple developers. I'll try to be
careful to update before I do any work. This will be big change of
habit because I normally just keep all the files open in an emacs
buffer for hours or days, but emacs is CVS aware so I just need to
read up on the cvs minor mode. I'll also follow your suggestions and
notify you if I make changes to the wx portion, and you can do the
same if you modify code outside the wx backend.
 Jeremy> In fact, it makes sense to say that backend_gtk should be
 Jeremy> the test bed for any architectural changes - when you're
 Jeremy> reasonably satisfied that things work, I'll implement
 Jeremy> equivalent changes in backend_wx. This will always put
 Jeremy> backend_wx slightly behind backend_gtk, but we can always
 Jeremy> ensure that they're back in sync for major releases.
This seems like a good idea. Even better is once you get wx in a
highly polished state, see if we can factor out a GUI backend
template. Ie, look for the commonalities in the GTK and WX backends
and factor them into base classes for both GUIs, and future GUIs to
come (possibly Tkinter)
 Jeremy> By the way, based on what I've found so far, the main
 Jeremy> areas I've found which caused me some confusion in
 Jeremy> implementing the backend are:
 - Think there should be a 'default' set of fonts with names common on
 each platform (I've implemented this)
Agreed. The PS and GD backends allow arbitrary fonts to be used, but
we should have a set of core fonts with common names for all
backends. A given backend can support more, but should try to support
the core. That said, it's hard to do. For example, the GD backend
uses true type fonts. The bitstream vera fonts are available under an
OS license so I distribute them. But I don't know about getting the
others -- I'll have to do some more research on what fonts come with
linux. It's not so bad under windows since there are a lot of ttf
fonts on a typical win32 install.
 - Should also be a set of common names for dotted lines - there are
 only four types, so no problem, I should think.
I don't have a problem with this. I disagree that my approach was
GTK-centric -- it's also supported in PS and GD. But I don't think
there's a need for total generality on dash-dot styles. We can do as
you suggest, set up a dict in the GC base class with the common names,
and let the derived classes do as they want with them
 - Somehow AxisText seems to be disconnected from the way the
 graphics are done. I managed to confuse myself quite a lot
 here. It seems to me that renderer is ultimately responsible fro
 rendering both text and graphics (on the same co-ordinate system)
I made it a separate class mainly to support handle graphics on text
objects. So you can do
 labels = ax.get_xlabels()
 set(labels, 'color', 'b')
or
 t = text(1, 2, 'hi mom')
 t.set_fontsize(12)
and so on. So text needs to be an object instance. It could be a
thinner wrapper than it is, but that is why I did it the way I did.
But there wouldn't be a problem with having the renderer implement a
draw_text method which took a text object rather than a string as an
arg, and move the drawing out of the AxisText class. It's probably a
good idea, just need to think about it a bit and make sure I can make
it work with the various backends.
 - I was also confused by the how scaling and co-ordinates are mapped
 to the device - this is probably a matter of documentation rather
 than design change.
This could definitely be improved. I need to make a clearer
distinction between the coordinate systems, and maybe generalize the
way internal data and transformations are stored, with a view to
supporting 3D. I'll put it on the back burner and let it simmer.
JDH

>>>>> "Jochen" == Jochen Voss <jv...@we...> writes:
 Jochen> Hello, I noticed several problems with the source archive
 Jochen> matplotlib-0.31.tar.gz.
Thanks,
I was doing the releases 'by hand' in a Makefile rather than using the
distutils sdist command, which I belatedly learned about. I've fixed
this, and written a python script to automatically generate the
LICENSE file with the proper version with each release.
Thanks for pointing these out,
JDH