Jeremy writes:
> 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.
> 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.
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.
> 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.
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)
> 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)
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