Re: gEDA-user: unpromoted visible attributes

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Fri, 2009-10-23 at 15:58 -0700, Jared Casper wrote:
> Hi all,
> 
> I'm working on a patch to libgeda and got in a little over my head so
> wanted to get some help/feedback...

This is a really nasty and troublesome issue, and there are lots of
subtleties which can catch you out - such as embedded complex objects.

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 hit all of these questions when looking at how to show "shadowed" or
overridden attributes in the multi-attribute editor. The conclusion I
came to was that since gEDA attributes have been so open-endedly defined
in the past - the functionality we are looking for here is not possible
without introducing additional constraints, such as rules for how an
internal attribute is considered over-ridden (and that its in-symbol
representation should be hidden).

> So I went ahead and added a promote-visible flag parallel to the
> promote-invisible flag, then in o_complex_is_eligible_attribute(), if
> promote-visible is false and the attribute isn't in
> always-promote-attributes, then don't promote it, even if it is
> 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.

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
object - which refers to an attribute by name (and / or some other means
to select an attribute if there are multiple with the same name). 

This would mean that when viewed in a schematic with "promoted"
attributes, the "magic" text field in the symbol takes on the correct
attribute value.

(You would of course, hide all the attributes in the symbol if using
this notional method)

> Another hiccup was when a complex is copied.  Previously,
> o_complex_remove_promotable_attribs() was called on the newly copied
> complex, which didn't make much sense to me since the source complex
> would already have them hidden or removed.

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

commit ea46d8defce4390b9650e8d2a5035de4794673df
Author: Peter TB Brett <peter@xxxxxxxxxxxxx>
Date:   Wed Aug 12 20:05:01 2009 +0100

    libgeda: Make o_complex_copy() actually copy. [2460301]

Before then the complex copy was quite a dance - where a brand new
complex was generated, its attributes promoted / removed.
(NB: Attributes are copied and re-attached separately).


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 ;)


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.

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:

http://repo.or.cz/w/geda-gaf/pcjc2.git?a=commitdiff;h=29a53f43e36e4c63666d375d70316f642374b09f
http://repo.or.cz/w/geda-gaf/pcjc2.git?a=commitdiff;h=81a80b0cbf808be81fba6ce0ccbc221856a1ba64

I'm looking to see much special casing of different attributes removed,
and relegated to very isolated modules of code that provide some
specific behaviour. slotting is my main hatred in that respect!


Best wishes,

Peter C.




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