> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:floatcanvas- > [EMAIL PROTECTED] On Behalf Of Bill Baxter > Sent: 03 June 2007 11:02 PM > To: Mailing List for the wxPython Float Canvas. > Subject: Re: [fc] Float canvas as a component w/ undo/redo > > On 6/4/07, Gerber, HR, Mnr <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > wrote: > > Chris and Bill > > > > I am currently building just such a library/framework for python, it > is loosely based on GEF (Graphics Editing Framework) (Trigris and > Eclipse each have their own implementations) and OGL. I studied them > all and designed my own based on what I thought they did well and what > one can do in python. I am still going to look at wxArt2D, as it is > probably the most similar to my library, but I don't just want to build > a clone as creating python binding might be easier. > > > That sounds perfect (except for the part about it not being done yet ;- > ) > I worked some on the low-level rendering code for wxArt2D, mostly in > making the Agg back-end more usable. But I'm not so familiar with > wxArt2D's high-level design. > > > > I have created a sourceforge project called pyGEF. There isn't > anything there yet but, it's a start. I will keep you informed. Anybody > want to help?? > > Sure, I'm interested. >
[Retief:] Great > > > pyGEF provides a typical editing environment with commands, tools, > undo, redo, load, save and many more. GEF does not rely on a specific > drawing canvas or drawing primitives. > > > > My first version of pyGEF used floatcanvas, while my second uses > GraphicsContext (GC). I build a layer onto GC so that it is similar to > floatcanvas, making my conversion easier. It would therefore be very > easy to support both drawing canvases as I make use of a Plotter class > that does the actual drawing (i.e. wrapping the GC\floatcanvas). It > should also be possible to use an OpenGL canvas for 3D visualization > and editing. > > That's excellent. I definitely like the separation of drawing > back-end, since I would also like to have the ability to use OpenGL if > the need arises. Sounds like this is an abstraction that would be > useful for FloatCanvas as well. Also AGG 2.4 as a back-end would be > nice too. Maybe code could be stolen from Matplotlib for that. > [Retief:] I have never hear of AGG, but will check it out > > I mainly started using the GC so that I can learn how it works and > because of the great looking graphics that it produces. > > Yes they look nice. By GC do you mean GCDC or are you using the > GraphicsContext's path-based API directly? [Retief:] I did not know there was a difference! I started with the wxPython demo and went from there. What makes the GCDC diffent from the GC? TO tell you the truth I am much more interested in the higher level stuff. Maybe we can make a good team. > > > Currently there is a problem with the GC in that it is really very > slow (floatcanvas is much faster), this makes GC unusable for projects > that draw more than a couple hundred components. GC is still very new > and will improve with time. I currently know too little about the inner > workings of GC to know if the performance decrease is because of my > possibly inefficient usage. :) My usage of it should also improve. :) > > I don't know what platform you are on, but neither Cairo nor GDI+ are > renowned for their speed. Agg is pretty much what everyone recommends > if you want reasonably fast AA drawing. [Retief:] GDI+ > > > I agree with Chris that the editing framework and the drawing canvas > should be two separate libraries. This would make each more powerful > and generic. > > I would go one further and say that the low level drawing should be > split out as well: > - low-level draw API/canvas that wraps > OpenGL/wxGC/GraphicsContext/FloatCanvas/AGG > - viewer component with an graphics-object model for graphical > entities and view-oriented tools > - drawing layer that can edit graphics-objects. > [Retief:] Agree > I think this is more or less how wxArt2D is structured. At least I > know that it has an abstracted low-level drawing API that is used > exclusively by the higher levels. > > > For those that are interested. > > > > pyGEF mini roadmap: > > Partially and completed work: > > The basic drawing canvas - GC\floatcanvas > > The basic primitive drawing objects - Line, > Polygon, Rectangle, etc. > > Beziers? [Retief:] I have not looked at them yet > > > The Command Structure - For the creation of actions > that can be undo. > > The CommandStack - For undo and redo. > > This I'm particularly interested in taking a look at > > > The Editor container - The document editing > container. > > Not sure what that does... [Retief:] The editor contains the document, commandstack and layermanager Send me you email address then I can send you document I set up, that explains a little bit more. There is a size limit on mails to the mailing list. I can also send you my current VERY BUGGY version so you can have a look. > > > The SelectionManager - Handling of selections like > multiple selections. > > The LayerManager and Layers - Handling the layers of > the document. > > The CreateTool - For the adding of new components to > the document. > > Seems like you maybe need more than one such tool, specialized for > each type of thing you want to create. [Retief:] Definitely, I actually already have quite a few of them. These are only the base classes that is used to create all the specialized versions. > > > The SelectTool - Handing of selection of document > components within the document. > > One thing you see often in vector editing apps is separate tools for > editing / selecting objects (global scale rotation etc), and for > selecting nodes (bezier control points, individual points in a > polyline). > [Retief:] Yes, that's why I have the Select and Modify classes of tools. > > The MoveTool - Handling the moving and rotating of > document components. > > > The ConnectTool - Handing the creation of connections > between document components. > > > > Next work: > > The EditTool - Handling the editing of component > properties. > > The ModifyTool - Handing the resizing and reshaping > of components. > > I guess in general I'm a little fuzzy on the high level design. It > seems like one tool for editing is not really sufficient because every > object has it's own special features. Hopefully it will be possible > to extend the framework with new kinds of graphical objects that have > their own set of parameters, and their own graphical handles that > allow manipulation of those parameters. I would hope that > box,circle,line,polyline,etc aren't just hardcoded as cases in one > giant do-all edit tool. [Retief:] Right again, at this stage my focus in the ModifyTool is allow scaling changes to the objects. In a vector base system this is rather generic for all types of object. But for more specialized editing capabilities one would need specialized tools. The detail of this still has to be figured out. But python should make this nice and dynamic. Especially as this lib is intended as a framework, users (i.e. developers) should be able to add custom objects and well as custom tools to manipulate these objects. > > > Make pyGEF compatible with both floatcanvas (Chris! > we will need to add some features to fc) and GC. > > Create an installer. (Can someone please help with > this as I have no idea how to create an installer!!!!!!) > > Creating python package installers is a piece of cake. See here: > http://peak.telecommunity.com/DevCenter/setuptools > [Retief:] I will have a look > Creating something that will work for someone who doesn't already have > python / wxPython / etc installed is more difficult. There's > something called py2exe that lets you make a stand-alone app out of a > python script, but nobody ever seems to be able to get it to work on a > non-trivial program. > [Retief:] I have had lots of practice with this one, and have gotten everyone to work (so far :) ). I must say it is quite an art to get some of them to work. This should not be a problem. > > > Place first release in SF (Two to Three months from > now). > > Why wait so long to upload to SF? If you don't add any developers > beside yourself others can only look. So if you're planning on > sharing the result anyway, might as well go ahead and check in what > you've got so others can check it out and comment / contribute. And > I'd suggest switching to SVN instead of CVS before you upload. Usage > is basically identical, but SVN allows you to rename directories > easily, which is very nice to have in the early stages of development. > [Retief:] As I said VERY BUGGY, but I will put up what I can. Maybe then you can help with the low level stuff. I am currently using my own SVN server, how would I go about converting the SF CVS repo to SVN?? [Retief:] I have not had a SF project before so I am still figuring out how it works. [Retief:] Would you like access to the project?? Anyone else?? > Regards, > --bb > _______________________________________________ > FloatCanvas mailing list > [email protected] > http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas _______________________________________________ FloatCanvas mailing list [email protected] http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas
