On Jul 15, 2008, at 1:25 AM, Peter Clifton wrote: > On Sat, 2008-07-12 at 08:54 -0700, [EMAIL PROTECTED] 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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
