Re: [Goocanvas-devel] Internal workings of goocanvas

[Carlos N. <cn...@ie...>]

El sáb, 14-04-2007 a las 12:02 +0100, Damon Chaplin escribió:
> On Fri, 2007-04-13 at 20:21 +0100, Peter Clifton wrote:
> > Sorry for the OT post...
> > (Its kind-of on-topic, but with off-topic motivation)
> > 
> > I have been pointed at Goocanvas by a friend, to look at using it for
> > drawing in an GPL EDA CAD package (gEDA).

Well, I'm that anonymous friend...  :)
 
gEDA is currently split in a library providing data structure
manipulation, and a drawing program. The complete suite includes some
command-line utils, linked with the library. 
Currently one of the things we are looking for is to simplify the
drawing code, as well as the data structure.

Basically, we are working with basic primitives (lines, rectangles,
circles, arcs, images,..) and objects (groups of primitives). We need to
store the position, angle and style properties of each object, as well
as properties (they are texts attached to an object, composed by two
texts: property name and property value). This "property" object has no
direct replacement as a goocanvas item, but I think it is not so hard to
create a new goocanvasitem just for them.

I see a great similarity with goocanvas items, and I think we could base
all our objects as goocanvas items. That would simplify the code a lot,
and it would be a great improvement to the drawing program: MDI
interface, simpler code (there is a lot of drawing code there).

One of the things we wouldn't want to loose is the split between the
library and the drawing program: as I mentioned there are command-line
utils using our library, and we don't want them to need the gtk library
just because we are using goocanvas items.

A quick look at the code shows that gtk functions are only used in
goocanvasatk.c, goocanvas.c, goocanvasstable.c, and goocanvaswidget.c .
Other files are including gtk.h, but it seems there is no gtk call
inside them.

Since a goocanvas widget is not needed in a command-line app, I guess
that maybe we can base the library on goocanvasitems (therefore without
needing gtk), and the drawing program can use the goocanvas widget.

I wonder what is the interface between goocanvasitems and goocanvas. Are
they connected just through signals? 

Another thing we are worrying about is drawing speed. I guess goocanvas
is going to be slower than the current implementation (GtkDrawingArea),
maybe just because its additional features. Some users are still using
slow computers, and we don't want to loose them.
I don't know if some features (antialiasing,...) can be turned off if
needed (can be?). Another possibility could be to use goocanvas items in
the library, but keeping the current drawing code (for GtkDrawingArea).

Therefore we can think some way to choose between using the goocanvas
widget or the current drawing code. If all the interface between
goocanvasitems and goocanvas widget is through signals, maybe we can use
them to draw to a GtkDrawingArea instead. Is this possible?

I would like to know your opinion about this, and any suggestion is
welcome. 

Thanks,

Carlos