geda-developers team mailing list archive

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

On Sun, 16 Dec 2012 12:21:29 -0800, ehennes@xxxxxxx wrote:
> 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 biggest benefit would be the property change notification
> available in GObject. I would suggest:
> 
> - Implement the page as a GObject
> - Implement OBJECTs as GObjects
> - Adding an OBJECT to page, the page connects to the OBJECTs' notify
event
> - Removing an OBJECT from a page, the page disconnects from the OBJECTs'
> notify event
> - OBJECT notify events of coordinate changes keep the R*-tree in sync
> 
> I believe the best benefit of this implementation is UI property
inspectors
> can
> modify properties on the OBJECTs and all the data structures stay in sync
> through notification events. It also makes it difficult for the
application
> using libgeda to do something that puts the data structures into an
invalid
> state.

Yes, I think that's a huge benefit.  I think that anything that ensures
that applications have to actually work really hard to break the state is
worthwhile.  Did you say that you have already got code that uses that
model?

> Unlike other languages, GObjects cannot have an reference to an interface
> as a property. If GObjects could contain a property of a EdaObjectSet,
> I would consider an abstract base class. The implementation could always
> contain a property of a GObject, but is cumbersome to get a pointer to
> the interface frequently, and the built-in type checking for the property
> does not work.

Ah, that's a pain.  What do you suggest instead?  Would it make more sense
for e.g. a page or attributable object to encapsulate the respective object
set?

Peter

-- 
Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre