On Tue, Sep 30, 2008 at 1:42 PM, Ales Hvezda <[EMAIL PROTECTED]> wrote:
> The one thing that bothers me about your abstract-symbols
> mechanism (yes I did try it a while ago) is that the end user has to
> instanciate two symbols instead of just one. From the example from the
> referenced post:
Thanks for the feedback.
> ...
> C 44100 44900 1 0 0 nand-1.sym
> ...
>
> and
>
> ...
> C 42300 41300 1 0 0 7400-slots.sym
^^^^^ ^^^^^
> ...
>
> That seems odd and I would have a hard time explaining that to
> end users. I like the idea of a "nand-1.sym" (yeah!), but I don't like
> the idea that you also have place a 7400-slots.sym.
I've tossed and turned about whether to make the "heavy" information
visible on the sheet or not. There's very little that *needs* to be
visible: you only need some way of editing refdes or other parameters
of the heavy part. The rest of the heavy symbol is just eye candy.
That's fixable though; it stands to reason that if there's a linkage
between the light and the heavy parts that allows you to edit the
heavy refdes and have it propagate to the light symbol, I could also
teach libgeda to propagate the info the other way, so you could edit
the refdes in an already-linked symbol and have it update in the heavy
part, and in all sibling light symbols. That would remove the need
for any of the heavy symbol to be visible.
If the heavy part has no visible graphical objects, its (x,y) location
is irrelevant, and it can just live at the origin or even (-1,-1) as a
hackish special value, placed there automatically by scheme callbacks
attached to the slot chooser menu items. To the user that translates
as "not having to place a 7400-slots.sym" - not explicitly anyway.
Would such invisibility for the heavy part of a symbol address your objection?
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
