Re: [matplotlib-devel] backend_wx update revision 1.9

[Jeremy O'D. <je...@o-...>]

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