Re: gEDA-user: unpromoted visible attributes

[Jared Casper <jaredcasper@xxxxxxxxx>]

On Fri, Oct 23, 2009 at 4:33 PM, Peter Clifton <pcjc2@xxxxxxxxx> wrote:
> This is a really nasty and troublesome issue, and there are lots of
> subtleties which can catch you out - such as embedded complex objects.
>

I figured as much... :)  Thank you for your detailed reply.

> There isn't an easy solution I can see, since it is impossible to define
> whether the in-symbol version of an attribute still "matters" to the
> back-ends. This wouldn't be so hard to define if we hate name=value
> where "name" is unique, but we already have cases where we support
> multiple "name=something_1" and "name=something_2" cases.
>
> When you have attributes with this "name" inside _and_ outside the
> symbol - which are wanted? Both? Does having one outside the symbol kill
> off or hide one or more _inside_, or does it add to the list?
>

I guess I was thinking I could avoid this complexity by just dealing
with whether or not an attribute was visible or not, not who masked
what.  But I guess since if keep_invisible=FALSE we are dealing with
more than visibility... and one could imagine a case where multiple
attributes with the same name should be visible..

> I'm not sure I welcome any more complexity in this area.. it is already
> very difficult to ensure code changes relating to attribute promotion
> are sound - and adding more options makes it harder. I do see why you
> want it though, but I'm not sure your way helps.
>
> I'm of the mind that we should (in an ideal world) _remove_ all
> automatic attribute promotion (perhaps excepting the special case of
> symversion), and define some new rules as to how an aggregate list of
> attributes is constructed from a symbol, and attributes inside the
> schematic.
>

I buy that, and would agree that automatic promotion is not the right
thing to be doing (as evidenced by my trying to be able to prevent
automatic promotion of every attribute except those that I explicitely
name :)  It's a tricky balance, as I would think you'd get the most
flexibility by not having much, if any, logic about attributes in
libgeda at all.  All it does is keep a lit of text objects that are
"attached" to an object and let the user of the library decide what to
do with that list.  However, that just moves the complexity to the
user of the library.  Gschem could know that an attached refdes should
be displayed instead of the symbol version, but what about some
attribute it doesn't know about?

> This might allow us to identify and hide attributes in the symbol which
> have been masked by attached (promoted if you will) attributes.
>
> We might be able to extend some syntax for explicitly "back annotating"
> the visibility of an attribute we no longer wish to see on the page.
>
> Yet another option - add some new file-format syntax for a special text
> ...
>

Maybe a flag in the text object inside a symbol that indicates if an
attached text object should override it or not? There are quite a few
options here, but none seem to be "perfect" :)

> Are you sure? I think that was deleted in this commit:
>

o_complex_copy() definitely still calls
o_complex_remove_promotable_attribs.  Not sure why though.

> I'm not in favour of any long term solutions which continue to keep a
> different in-memory representation of a symbol as it loads from disk -
> that includes not removing / hiding attributes ;)
>

if libgeda doesn't touch what is defined in the .sym file, then gschem
is going to need to gain some smarts.  Every symbol has a visible text
object like refdes=R?, and gschem will have to learn not to show this
if there is an attached refdes (just as one example).

> Sorry to be both negative, and rather speculative in my reply. This is a
> complex area (no pun intended), and there are no obvious easy answers.
>

No worries, after hacking for an hour I realized I was in over my head
and that an hour or two wasn't going to cut it.  And while I had a
solution that was "working", I was skeptical. :)

> BTW.. if you're looking at gEDA attributes, take a look at some of the
> code I've got queued up for some time in the 1.7.x development cycle
> relating to event based attribute processing:

I'll take a look if I get a chance.

> Best wishes,
>
> Peter C.
>

Thanks again for your quick and detailed reply,

Jared


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user