Dj Gilcrease wrote: > Yes better integration is always good so someone does not have to > subclass every object and write their own _draw method
we're all on the same page here.. >> you can show/hide objects, but I'm not sure what you mean by events -- >> do you want en event raised when a object is shown/hidden? > > Yes I would need events for all of those, and looking back at my old > code, which I did have these events, it shouldnt be to hard to add > them to FC no. FC raises custom events already. Always because of a wx event, but that shouldn't make a difference. > Looks like Enthought has not released anything since 2006 and does not > support Python 2.5. Their stuff is under quite active development. In fact, they just released a beta of the Enthought Python Distribution: http://www.enthought.com/products/epd.php which is built on Python 2.5 I think their stuff is as supported as pretty much any OS package -- plus we'd still have the source. Where there have been issues is in how their stuff has been intertwined -- it's been hard to use one of their packages without using all of them, but they've been working on cleaning that up. The other issue with Kiva, is that while it's intended to be back-end independent, I don't know how many back ends they really support. wx is their main platform, though. I'm also very interested in using Enthought Traits -- it looks very well suited to this kind of thing. > How I have this mapped out in my design docs for what I was writing is > each object contains all the info that would be required to draw it > regardless of toolkit, but not the drawing method (as thats tied to > the toolkit), The issue with that that is that then when you create a new DrawObject, you need to write a draw method for each back-end supported -- not a big deal with a small number of back-ends, and a small number of DrawObjects, but it doesn't scale well. However, it's the easiest way to do it, and I'm content with only supporting wx now anyway (though PDF, and maybe SVG would be nice...) > so > for my needs the object cannot be tied to a toolkit, it should be the > particular canvases job to inset the proper drawing method. I've taken a look at the current DrawObject code, and the only place wx is used in is the Brush/Pen/Font caching system -- which is something that I think is almost useless, and I was planning on ripping it out anyway. > I had all the events I listed plus selection and deselection events > and didnt have an event abstraction layer, I just used > wx.PyEventBinder to create the events write, but if you want it to work across back ends, then you need to abstract that somehow too -- but maybe that's not a big deal -- all you need is to have universal names for the events, and each back-end would require a different Bind method, much like each back-end requires a different Draw method. I'm wondering if we should use something like wx.lib.pubsub, it might be easier and more flexible, and it's not tied to wx (despite living there). I guess it's time to start up some Wiki pages for this.... -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
