Hi Retief, Thanks for the note -- this looks very exciting!
I forwarded your note (and this one) to the mailing list, I'd love to get other's input on this. If you're not on the list, please join, it's very low traffic: http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas Also, if you haven't seen the TRAC project and SVN, here it is: http://morticia.cs.dal.ca/FloatCanvas/ I don't have much time right now to look at your code, but I'm commenting below for now. > Have you ever heard of GEF (Graphic Editing Framework) Tigris and > Eclipse both have a version of essentially the same thing. I haven't heard of it before. > Currently there is no such library available for Python. Searching > around on the net a bit a found many people also looking for a library > exactly like this. Yes, there are. Indeed, someone just joined the mailing list looking for some of this functionality. > Floatcanvas is excellent at presenting something graphically, but it > lacks real editing capabilities. Quite true -- it's been on my list for a while, but who has time? > Granted this editing functionality can > be implemented on the application side. The problem is that most people > do not know how to do this properly. GEF defines a nice generic > framework that can be used to do most of the grunt work and lets the > developer worry about the application logic instead. This does sound cool. I've been a bit reluctant, as I think different apps have different editing needs. However, putting a framework in place that can be customized makes a lot of sense. > GEF does rely on the presentation layer to do a bit more of the work > than floatcanvas currently does. This is mostly because GEF uses Java > and the java GraphicsContext is a bit more advanced than the wx > DeviceContext (I think in any case). Probably so. Have you looked at the new wxGraphicsContext? I've been meaning of looking at that, and seeing of using it for FloatCanvas makes sense. If nothing else, I'd like to get alpha blending. > Here is a quick list of features that might have to be added to > floatcanvas (please comment): > > Move, Rotate ( or Transformations) of all primitive DrawObjects It already has Move, but the others would be good too -- maybe a generic affine transform, then some convenience functions for the basics. I think the code could be put into the Mixins (XYObjectMixin, PointsObjectMixin), so you wouldn't need to write too much code for each DrawObject. > CompositDrawObjects I've added "Groups", though that's not quite the same. > MultipleLayers (and LayerManagers) ( The HitCanvas should also be > multi-layer, to solve the hitting problem with overlapping objects) Yes, though that gets a bit resource intensive, as it would need an off-screen bitmap for each layer. > The OnHitTest API should be changed What do you have in mind? I do think it's pretty ugly now, though. > Serialization (For saving “designs”) That would be nice too -- a minimal version of SVG maybe? Alternatively, I was thinking of re-factoring the DrawObjects to store all their properties in a single dict -- most of the keys (LineColor, etc) would be common to other DrawObjects, and then you could just pickle (or otherwise save) that dict, and you'd have serialization. Also, that would make it easier to make a GUI Object Properties editor -- you could just scan the dict for what properties that object has. Considering "traits" is a god idea too: http://code.enthought.com/traits/ > The handling of events should be changed to conform to the GEF pattern > (see my code on how I implemented “Tool’s”) that is quite a bit more > scalable than the GUIMode currently used. I had high hopes for GUIMode, but haven't really applied it to anything non-trivial yet -- I'm looking forward to seeing what you've done. > Let my know if you have any questions! will do when I get a chance to really check it out. > 1. The entire SchemCore lib should be integrated with floatcanvas > (Only contains extensions of Drawobjects) I've been planning on putting all the DrawObjects in their own module anyway -- a good time to re-structure. > I think pyGEF could be a nice extension to or demo of floatcanvas. They > could stay two separate libs or be integrated into one. We'll see how that goes. I've always had it in mind that FloatCanvas is really about presentation -- so if we can keep it separate easily, that would be nice -- but I'd love to have something like this as part of the standard distribution. > What do you think? I haven't even tried it yet, but I'm thrilled! thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] _______________________________________________ FloatCanvas mailing list [email protected] http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas
