matplotlib-devel Mailing List for matplotlib (Page 554)

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

Hello,
I noticed several problems with the source archive
matplotlib-0.31.tar.gz.
1) The licence file confuses version 0.30 with version 0.31.
 (I mentioned this already to John.)
2) There are several editor backup files included in the archive:
 voss@plonk [~] tar tfz matplotlib-0.31.tar.gz | grep '~'
 matplotlib-0.31/matplotlib/backends/backend_gtk.py.~1.10.~
 matplotlib-0.31/matplotlib/matlab.py.~1.22.~
 matplotlib-0.31/matplotlib/axes.py.~1.14.~
 matplotlib-0.31/matplotlib/_matlab_helpers.py.~1.4.~
 matplotlib-0.31/examples/log_demo.py.~1.2.~
 matplotlib-0.31/examples/interactive2.py.~1.1.~
 matplotlib-0.31/examples/legend_demo.py.~1.5.~
 matplotlib-0.31/examples/stock_demo.py.~1.2.~
 These should be removed (i.e. not included in the next version).
3) there are two CVS directories in the source:
 voss@plonk [~] tar tfz matplotlib-0.31.tar.gz | grep CVS
 matplotlib-0.31/matplotlib/backends/CVS/
 matplotlib-0.31/matplotlib/backends/CVS/Root
 matplotlib-0.31/matplotlib/backends/CVS/Repository
 matplotlib-0.31/matplotlib/backends/CVS/Entries
 matplotlib-0.31/examples/data/CVS/
 matplotlib-0.31/examples/data/CVS/Root
 matplotlib-0.31/examples/data/CVS/Repository
 matplotlib-0.31/examples/data/CVS/Entries
 These should be removed (i.e. not included in the next version).
I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hi John
On Thursday 06 November 2003 3:57 pm, John Hunter wrote:
> Jeremy> My Debian machine is Python 2.3, and it seems to work
> Jeremy> there. As I mentioned, the code seems (on Linux) to need
> Jeremy> to run in a PyCrust shell at the moment - I need to fix
> Jeremy> this, but I suspect that it means getting bogged down in
> Jeremy> details of how the event loop works, which I'd rather put
> Jeremy> off until the main backend is stable.
>
> I think this is not too hard. I created a
>
> wxapp = wxPySimpleApp()
>
> at the top of backend_wx (to solve the bitmap problem). Then in
> ShowOn.realize_windows I called wxapp.MainLoop(). With these changes
> I can call
>
> > python simple_plot.py -dWX
Thanks for fixing this. To be honest, my main focus is using matplotlib inside 
an applications, which is why I hadn't looked into this, beyond ensuring that 
it works in a PyCrust (which is my usual interactive shell, to be honest)
> Thanks for the CVS info. You'll need to get a sourceforge account if
> you don't already have one, and send me your user name. Then I'll add
> you as a developer so you can have write access to the repository.
My Sourceforge user name is jodonoghue
> I'll do some reading up on CVS. What happens if we both check out a
> copy of the wx backend and make changes to different functions in the
> same file, and then both check the code back in? Will CVS
> automagically update the separate parts of the file, or will the
> second person get an error saying "You can't check this in because the
> CVS file has changed since you checked out", or what?
CVS, like most SCM tools, doesn't help you quite this much. All it really does 
is to keep a diff every time a new file is committed, so it is quite possible 
that if you make a change to a file, and then I check in a new change without 
an update, HEAD would 'loose' your update (although it would be easy using a 
CS diff to determine the 'lost' code.
Normally CVS is configured so that files are checked out 'unlocked' - i.e. 
more than one developer can check out a file (so a check out is 'advisory' 
only).
Here's how I work in CVS:
I have a local mirror of CVS tree, which I regularly update to head. From this 
I copy files to my matplotlib development directory. When I wish to check in 
an update, I do an update on my CVS copy, and diff the new file with the CVS 
copy. There are two possibilities:
1) Any changes to HEAD are on lines I haven't changed. In this case
 (which is the most usual) I just have to do run merge between the
 files and then commit (having regression tested, of course).
2) We have made incompatible changes (e.g. both fixed the same bug
 in slightly different ways, or added new code in the same place). In this
 case I have to do a manual merge on the files, taking parts from both
 and working until regression tests pass - then commit.
One way to avoid this kind of issue is to (informally, CVS doesn't let you 
enforce this) say that only one person will normally work on a given file - 
in practice, this is how we operate at work (but then we have a 10,000 file 
source tree, so everyone would go crazy if we didn't). If someone has a fix 
for a file, they send it to the file maintainer, and ask him/her to 
incorporate the patch. This is basically how Linus maintains Linux (there are 
only a very small number of people who have commit rights to the Linux CVS 
tree - maybe 10 or 20 of the thousands of developers.
> I made a couple of small changes to your code (BTW, I don't know if
> matplotlib-devel is working because none of my emails have made it
> through). The images dir is now in the matplotlib root (where
> setup.py and the fonts dir reside). The distutils installer puts them
> in the matplotlib shared dir for data files, and I changed
> _load_bitmap to look for them there. This maintains consistency with
> how I deal with other data files, eg, font files.
All of your changes seem eminently sensible. You have done an excellent job of 
architecting matplotlib, and I'd rather let you keep things designed as you 
prefer them. We can (and should) discuss any architectural changes, but I'll 
implement whatever you finally decide.
In fact, it makes sense to say that backend_gtk should be the test bed for any 
architectural changes - when you're reasonably satisfied that things work, 
I'll implement equivalent changes in backend_wx. This will always put 
backend_wx slightly behind backend_gtk, but we can always ensure that they're 
back in sync for major releases.
By the way, based on what I've found so far, the main areas I've found which 
caused me some confusion in implementing the backend are:
- Think there should be a 'default' set of fonts with names common on each 
platform (I've implemented this)
- Should also be a set of common names for dotted lines - there are only four 
types, so no problem, I should think.
- 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 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.
Regards
Jeremy

Receiving you loud and clear.
I did receive all of the other mails at my personal address.
Jeremy
On Thursday 06 November 2003 7:13 pm, John Hunter wrote:
> OK, if you think I've been ignoring you on this list there is a reason
> -- I wasn't subscribed. I assumed because I am the list admin that I
> would automatically be subscribed. So as far as I know, despite my
> earlier complaints and tests, this list is working.
>
> Can you hear me now?
>
> JDH
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

OK, if you think I've been ignoring you on this list there is a reason
-- I wasn't subscribed. I assumed because I am the list admin that I
would automatically be subscribed. So as far as I know, despite my
earlier complaints and tests, this list is working.
Can you hear me now?
JDH

 Jeremy> My Debian machine is Python 2.3, and it seems to work
 Jeremy> there. As I mentioned, the code seems (on Linux) to need
 Jeremy> to run in a PyCrust shell at the moment - I need to fix
 Jeremy> this, but I suspect that it means getting bogged down in
 Jeremy> details of how the event loop works, which I'd rather put
 Jeremy> off until the main backend is stable.
I think this is not too hard. I created a 
 wxapp = wxPySimpleApp()
at the top of backend_wx (to solve the bitmap problem). Then in
ShowOn.realize_windows I called wxapp.MainLoop(). With these changes
I can call 
 > python simple_plot.py -dWX
and it launches!! I am very excited about this wx backend, by the
way.
 Jeremy> I have no worries about dealing with several people on CVS
 Jeremy> at the same time. At work we have about 50 developers
 Jeremy> working on the same codebase (admittedly with a slightly
 Jeremy> more heavyweight SCM tool). Basically the rules are:
Thanks for the CVS info. You'll need to get a sourceforge account if
you don't already have one, and send me your user name. Then I'll add
you as a developer so you can have write access to the repository.
I'll do some reading up on CVS. What happens if we both check out a
copy of the wx backend and make changes to different functions in the
same file, and then both check the code back in? Will CVS
automagically update the separate parts of the file, or will the
second person get an error saying "You can't check this in because the
CVS file has changed since you checked out", or what?
I made a couple of small changes to your code (BTW, I don't know if
matplotlib-devel is working because none of my emails have made it
through). The images dir is now in the matplotlib root (where
setup.py and the fonts dir reside). The distutils installer puts them
in the matplotlib shared dir for data files, and I changed
_load_bitmap to look for them there. This maintains consistency with
how I deal with other data files, eg, font files.
Also, I added a KNOWN BUGS section to backend_wx.py where I pasted in
those from your email and added some I came across while running most
of the demos. We can both use that area to keep up with known bugs
and fixes.
JDH

My last post didn't make it through. Testing 1 2 3

Hi John,
I'm getting on reasonably well with the wxWindows back-end, and would be
nearly ready to release something for 'early adopters', but for one small
problem:
I can create figures with multiple sub-plots (I've tried most of the
examples on the web page), using colour and so on...
But all of my plotted values are inverted - that's to say, the origin of
each set of axes (from the point of view of plotting) is in the top left,
with increasing values going downwards.
The axis scales are correct, and all of the patches are in the right place.
I'm sure that I have my co-ordinate conversion mixed up somewhere, but to
understand what is happening, it would be useful to have a brief
explanation of the virtual co-ordinate system used internally in
matplotlib, and (especially) how internal co-ordinates should be converted
to device co-ordinates.
This is all quite confusing - I had originally assumed that I should be
subtracting the window client area height from all y axis co-ordinates,
but this really messes things up for multiple sub-plots (BTW, wxWindows
normally sets the origin in the 'natural' (i.e. bottom left) of a window.
Thanks
Jeremy

Hi John,
I've implemented xerrorbars and xyerrorbars commands.
I did this by adding two extra functions to the matplot.py rev 1.25
Your code makes it trivial.
As matlab seems not to have x or xy-errorbars, I took my inspiration from
Gnuplot when deciding whether to implement the different versions as
separate commands or as different formats of parameters to errorbars
command. However, since I haven't discussed this with you and just went
ahead and did it, I'll just provide the diffs here (and email you the
matplot.py file offlist to save you patching it).
Also, the xyerrorbars function just naively wraps the errorbars and
xerrorbars functions. This means that the plot symbol is rendered twice for
each point which is probably not ideal. If you see this as a problem, I can
redo it - let me know.
On the same topic, I see you just changed the bar end size ratio from 0.005
to 0.001.
The bar ends are now quite small and I don't think 0.005 was excessive, so
I'd be inclined to revert it back although I guess you had a reason.
Gnuplot makes the bar end size a settable parameter which would be a better
solution IMHO.
regards,
Gary
---8<---Cut here---8<---
185a186,187
> xerrorbar - make an errorbar graph (errors along x-axis)
> xyerrorbar - make an errorbar graph (errors along both axes )
195c197
< 'figure', 'gca', 'gcf', 'close' ]
---
> 'figure', 'gca', 'gcf', 'close', 'xerrorbar', 'xyerrorbar' ]
372c374,407
< def errorbar(x, y, e, u=None, fmt='b-'):
---
> 
> 
> def xyerrorbar(x, y, e, f, u=None, v=None, fmt='b-'):
> """
> Plot x versus y with x-error bars in e and y-error bars in f.
> If u is not None, then u gives the upper x-error bars and e gives the
lower
> x-error bars.
> Otherwise the error bars are symmetric about y and given in the array
e.
> If v is not None, then v gives the upper y-error bars and f gives the
lower
> y-error bars.
> Otherwise the error bars are symmetric about x and given in the array
f.
> 
> fmt is the plot format symbol for the x,y point
> 
> Return value is a length 2 tuple. The first element is a list of
> y symbol lines. The second element is a list of error bar lines.
> 
> """
> errorbar(x, y, e, u, fmt)
> xerrorbar(x, y, f, v, fmt)
> 
> 
> def xerrorbar(x, y, e, u=None, fmt='b-'):
> """
> Plot x versus y with error bars in e. if u is not None, then u
> gives the left error bars and e gives the right error bars.
> Otherwise the error bars are symmetric about x and given in the
> array e.
> 
> fmt is the plot format symbol for y
> 
> Return value is a length 2 tuple. The first element is a list of
> y symbol lines. The second element is a list of error bar lines.
> 
373a409,432
> l0 = plot(x,y,fmt)
> 
> e = asarray(e)
> if u is None: u = e
> right = x+u
> left = x-e
> height = (max(y)-min(y))*0.001
> a = gca()
> try:
> l1 = a.hlines(y, x, left)
> l2 = a.hlines(y, x, right)
> l3 = a.vlines(right, y-height, y+height)
> l4 = a.vlines(left, y-height, y+height)
> except ValueError, msg:
> msg = raise_msg_to_str(msg)
> error_msg(msg)
> raise RuntimeError, msg
> 
> l1.extend(l2)
> l3.extend(l4)
> l1.extend(l3)
> draw_if_interactive()
> return (l0, l1)
> 
374a434,435
> def errorbar(x, y, e, u=None, fmt='b-'):
> """