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.
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??
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.
I mainly started using the GC so that I can learn how it works and because of
the great looking graphics that it produces.
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 agree with Chris that the editing framework and the drawing canvas should be
two separate libraries. This would make each more powerful and generic.
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.
The Command Structure - For the creation of actions that can be
undo.
The CommandStack - For undo and redo.
The Editor container - The document editing container.
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.
The SelectTool - Handing of selection of document components
within the document.
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.
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!!!!!!)
Place first release in SF (Two to Three months from now).
Regards
Retief
Retief Gerber
Lektor
Lecturer
Departement Elektriese en Elektroniese Ingenieurswese
Department of Electrical and Electronic Engineering
Tel: +27 21 808 4011 I Faks/Fax: +27 21 808 4981
E-pos/E-mail: [EMAIL PROTECTED]
Universiteit Stellenbosch University
Privaat Sak/Private Bag X1 Matieland 7602
Suid-Afrika/South Africa
www.eng.sun.ac.za
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:floatcanvas-
> [EMAIL PROTECTED] On Behalf Of Christopher Barker
> Sent: 03 June 2007 08:44 AM
> To: Mailing List for the wxPython Float Canvas.
> Subject: Re: [fc] Float canvas as a component w/ undo/redo
>
> Bill Baxter wrote:
> > I was thinking about drawing a component for an app, and how to deal
> > with communication between the host app and the drawing component,
> and
> > dealing with undo/redo, and with giving the component toolbars etc,
> > when it occurred to me that the STC text control [*] solves a very
> > similar problem, it just provides an interface to a rich text
> document
> > model rather than a drawing document model. All the issues that it
> > has to deal with are pretty much the same. It might be a good idea
> to
> > copy its API.
>
> I've never used STC at all, so thanks for the suggestion. I should take
> a look at it.
>
> I've been thinking about this some, and one issue I have is that I"m
> not
> sure what role FloatCanvas itself should play. I've really always
> thought of it as the Viewer part of any potential app. I think various
> different uses are going to require fairly different types of
> documents,
> so we really don't want the whole document model built in to
> FloatCanvas. However, FloatCanvas should "play well" with those various
> document models.
>
> As an example, I think STC is really designed not for all types of text
> documents, but really code in particular, and I don't think it plays
> all
> that well with other types of docs.
>
> I haven't really built anything yet that really had "documents", but
> I've figured that when I do, I'll create Graphics objects that are used
> in the document that are subclassed from FloatCanvas DrawObjects.
>
> > Anyway I could use something like a
> > drop-in figure editing component. Maybe that's what OGL is though?
>
> It depends on what type of figures your talking about. My impression of
> OGL is that it is designed for boxes-connected-by-lines type drawings.
>
> > Then there's wxArt2D too, but I don't think there are py bindings for
> > that.
>
> Nope. and I understand that it uses a lot of Virtual method which makes
> wrapping it a pain.
>
> > I never paid much attention to OGL because it was all aliasy.
> > But maybe now with the new GCDC it's gotten a facelift?
>
> Only if someone as adapted the code. And FloatCanvas is using the same
> old aliasy DCs too. (though see recent messages here from HR Gerber,
> he's been playing with the new GraphicsContext, with some nice results.
>
> Anyway, I'd love someone to build a nice figure editor with
> FloatCanvas,
> hint, hint.
>
> -Chris
>
>
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> NOAA/OR&R/HAZMAT (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
> _______________________________________________
> 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
