backend_wx update revision 1.9

Development matplotlib-devel
1

I have just made a further update to backend_wx. Details

    > 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

2

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:

    > I have just made a further update to backend_wx. Details
    > 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

backend_wx.py (49.5 KB)