geda-developers team mailing list archive

[Edward Hennessy <ehennes@xxxxxxxxxxxxx>]

On Dec 15, 2012, at 5:41 PM, Peter TB Brett wrote:
> I'd really appreciate any and all comments and/or feedback that you
> could give me.  These will all fall in the "serious refactoring" bucket,
> and I would really appreciate some sanity checking to ensure that I'm
> not going to run into a snag that someone else could have spotted for
> me!

I think the best improvement would be using the GObject property change
notification. If both the page and OBJECTs get implemented as a GObjects,
the page can use the notify event to keep the R*-tree in sync with all
the coordinates of the OBJECTs.

The value of this approach is the all the data structures in the library
can stay in sync when a UI property inspector makes changes to the OBJECTs.
It also makes it difficult for an application using libgeda to put the
data structures into an invalid state.

> My suggestion is therefore to introduce an EdaObjectSet as a gobject
> "interface" to be implemented wherever it makes sense to handle a set of
> objects.  It would then be possible add a "default" EdaObjectList class
> that provides a default implementation for the interface and could be
> used as the basis for turning the schematic page structure into a
> GObject with useful signals.

Unlike other languages, GObjects cannot have a pointer to an interface as
a property. If the EdaObjectSet might be a property of a GObject, I would
suggest an abstract base class. Although a GObject can have a reference to
another GObject, getting a pointer to the interface is cumbersome and the
built-in property type-checking provide the value it could.

Cheers,
Ed