Thanks for sending the patch, Its good to see what everyone is doing.
(I'll try to keep on top of sending updates / posting links to code for
the stuff I'm doing. To summarise, that is some drawing fixes, desktop
integration and (more slowly), various (invasive) libgeda + gschem
refactoring.
Some comments...
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,
as I'm not fully up to speed on the various design patterns for this
sort of object creation.
Can you define some terminology please? I think I know what you mean,
but please bear in mind that I (and perhaps others) don't have a formal
computer science background. (Ideas I understand, just sometimes the
terminology obfuscates those ideas).
Factory (function delegated to for creating objects which match
the interface / have similar ancestry to a requested type) (?))
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. (?)
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?
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.
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?
Decorated (adding something to an existing object (?))
I don't like this term in a GUI app. I spent too long for
comfort thinking a decorated text object was something which
would look pretty on screen ;).
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?
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?
> Where am I going with this? My other patch needs to rewrite pinnumber
> attributes from within libgeda. Since libgeda can no longer directly
> draw stuff (it's cleaner that way), it needs to tell gschem to redraw
> the text.
Being a pedant:
s/tell gschem to redraw the text/tell gschem the text has changed/
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.
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
