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)
>>>>> "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
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 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