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 -- Mailing list: https://launchpad.net/~geda-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~geda-developers More help : https://help.launchpad.net/ListHelp
