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