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.


> 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.

> 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?

> 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.

> 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.

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?

>                 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...

>                 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.

>                 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).

>                 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.

>                 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

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.


>                 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.

Regards,
--bb
_______________________________________________
FloatCanvas mailing list
[email protected]
http://mail.mithis.com/cgi-bin/mailman/listinfo/floatcanvas

Reply via email to