On Nov 13, 2007 4:04 PM, Peter Clifton <[EMAIL PROTECTED]> wrote: > On Tue, 2007-11-13 at 15:13 +0200, Bernd Jendrissek wrote: > > After some of Peter C's work, my earlier first-class-slots patch > > broke. To fix it, I've taught libgeda to create text objects through > > a factory, so that gschem can provide its own factory that produces > > decorated text objects. Decorated with an Observer that redraws the > > text when the text string changes. Seems to Work For Me (tm). > > I looked at the patch briefly, and it seems interesting. I'm not sure > its the direction I'd have gone in, but give me time to let it sink in,
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! > Factory (function delegated to for creating objects which match > the interface / have similar ancestry to a requested type) (?)) The "ancestry" is not so interesting here. The delegation is. > As I understand it, your code gives libgeda a factory for > creating "boring" objects. gschem replaces this with a new > factory for creating objects it can keep track of. (?) That's exactly right. > I don't really like this, but can't place why. It might be > the fact that it appears to require duplication of factory > code between libgeda / gschem. I see you're currently just > calling libgeda's factory functions from the gschem ones. > Will these be fleshed out later? The libgeda factory is necessarily "boring" - it's the base class in the Abstract Factory pattern. The duplication is a little silly I suppose; I could just initialize the gschem factory's methods with pointers to the libgeda factory methods. In C++ it would be trivial - the linker (?) would do all that method pointer copying for you. 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. > 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. > 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. > 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. > Being a pedant: > s/tell gschem to redraw the text/tell gschem the text has changed/ ACK. It is / should be completely internal to gschem that it maps "changed" to "redraw". > Is related to the slotting changes you're working on? Would it be > possible to send a brief description of that again? I don't feel that > those suggestions got enough consideration when you first sent them - so > perhaps a summary would be in order. 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.) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
