On Tue, 2007-11-13 at 18:07 +0200, Bernd Jendrissek wrote: > Actually someone could probably do it more neatly by making OBJECT a > derived class from GObject, then we'd have all the observer stuff > (g_signal_connect and friends) "for free". I just wanted something > working yesterday!
Peter B has been looking at this, perhaps he'll reply. > I certainly hope that over time more of the prim_objs and other > drawing-only artifacts can move out of libgeda and into gschem > specializations. For instance, you could override the TEXT factory > method to return something that has a handle to some pretty pango > text. That is certainly I'd like to see. (At least as an experiment). prim_objs for a "complex" will probably want to remain, or more ideally, point at a single (ref counted) instance of the symbol graphics representing that complex / sub-circuit in memory. > > I think a possible reason this feels wrong to me, is that we > > might want observers with different behaviours. Lets say I > > have a plugin which might work with gnetlist / gattrib / gschem > > and it wants to do something special with objects in the same > > way the gschem factory might hook them. Since there is only one > > factory (or objects might exist before I can chain in a factory) > > I don't see how this would work. > > There's a factory per TOPLEVEL. Not sure if that answers your question. I'm not sure it allows other non-integrated code the same chance to hook object creation, that is all. > > Can we achieve an observer / signalling pattern without the > > factory? What hooks / signals do you need to use? Would it > > require a way to "stash" gschem / .... / specific data against > > the objects in libgeda? > > Yes, I suppose you could do it with hooks instead. But think of the > Abstract Factory pattern as representing a compile-time chain of hooks > that are connected by the links in the inheritance tree. I'll try to read up on the factory pattern, and perhaps look at some other places it is used. Compile time is probably not that helpful for the possible plugin case. Whilst we don't yet _have_ plugins, I wouldn't want to exclude the possibility of them. > > Decorated (adding something to an existing object (?)) > > I couldn't think of a better word that didn't have some gang-of-four > connotations. > > > Correct me if I'm wrong, but is what this code does: hook > > object creation to attach a "changed" signal handler to new > > text objects? > > Yes, that's what the code does. > > > I think a "changed" signal in libgeda, called out to any registered > > "interested parties" (e.g. gschem's redrawing) would suffice for the > > case here. Am I missing something? > Hmm, I thought that's what my patch does? I just *also* needed the > factory so that gschem can pick up *new* objects as they get created. Sure, I read that bit more closely after I posted the last email. It was the factory which thew me most. I will apply the patch bundle to a real git repository and view the complete delta. That should make it easier to view from a higher level. I wonder if we could register a handler for a particular class of signals. For example.. "page changed". Adding more detailed signals might give say, "object added", "object removed", "object changed" etc. These would be attached to the TOPLEVEL / PAGE in question, rather than the individual object. This would avoid the need to hook object creation. It could still be notified if desired with the "object added" signals. Within libgeda, doing something like adding an object would call some generic page notifcation function, which could then emit back to gschem and all others who've registered. I'll apologise in advance for not having yet read and worked out how this would effect the redraw signal handlers you're using. [snip] > My slotting changes separate the heaviness from the lightness in the > symbol library. It lets you define light symbols with only abstract > pinfunction= attributes, and heavy symbols that have no pins of their > own, but have first-class slots into which you can fit light symbols. > The heavy symbol then completes the mapping from the abstract > pinfunction= attribute to the heavier pinnumber= attribute. There's > also a pretty slot chooser dialog that presents a constrained choice > of available slots. (To prevent you from putting a BPJ into an opamp > slot.) Cool, when you've got some, please post screen shots! I'm not fully picturing whether the schematic will just look like it has light symbols in, or if any graphical representation of the heavier symbol is made. Do you have the user add attributes on instance of the light symbol to reference the heavy symbol, or do you instantiate both on the page? Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
