Re: gEDA-dev: Converting OBJECT to use GObject as a base

[ehennes-at-NOSPAMsbcglobal_dot_net]

On Jul 15, 2008, at 1:25 AM, Peter Clifton wrote:

> On Sat, 2008-07-12 at 08:54 -0700, ehennes@sbcglobal.net wrote:
>> Hi Everyone,
>>
>> I was experimenting with creating a property editor for schematic
>> objects (x,
>> y, color, etc...).  Receiving notification of property changes seems
>> to be one
>> of the difficult hurdles with this implementation.  To me, it would  
>> seem
>> beneficial to convert OBJECT to use GObject to enable the use of
>> signals.
>
> I'd want to take a look at the overheads of connecting lots of signals
> to every line, net segment / other object on the page. As an example;
> Goocanvas short-circuits its GSignal based notifications when there is
> only a simple case with one model / controller.
>
I don't see a problem when the user changes a single property on a  
single OBJECT.  However, in the case where the user changes the x and  
y properties of every OBJECT on the page, I'm not so certain.  Is this  
the GSignal overhead you are concerned with?  I think it would be  
relatively easy to make a performance test and measure the result.   
Did you have an idea of a worst case scenario?

>> The archives had some mention of changing OBJECT to use GObject as a
>> base, but I didn't see any consensus to that direction.  What is the
>> current sentiment on using GObject as a base for OBJECT and using
>> signals for property change notification?  Would there be a preferred
>> alternate mechanism for property change notification?  Or, has anyone
>> already undertaken a project to implement this functionality?
>
> There is also an argument that we might want to keep the low-level
> back-end library as independent as possible from other technologies  
> (at
> least to its users). E.g. if it uses GObject / GSignal internally,  
> that
> shouldn't be exposed at the boundary layer.
>
> Granted, libgeda isn't all as low level as I'm thinking here. It
> contains various things which could combine with parts of gschem to  
> make
> a "libgschem". I'd imagine that exposing one or more GtkWidget, and  
> use
> of GObject would be much more appropriate there.
>

I wondered about a place to put reusable gEDA GTK widgets.  The  
archives mentioned removing libgeda's dependence on GTK, and in  
another place about libgeda including reusable GTK widgets.  Having  
straight C structs and functions in one library, and GObject wrappers  
and reusable GTK widgets in another library seems like a good idea to  
me.

Cheers,
Ed


_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev