[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: "Inherited" attributes view in gschem



On May 31, 2009, at 8:23 AM, Peter Clifton wrote:

> Hi guys,
>
> I've just dropped in some code changes which give the multi-attrib
> editor in gschem the ability to view attributes from inside symbols.
>
> Screenshot here:
> http://www2.eng.cam.ac.uk/~pcjc2/geda/screenshots/ 
> inherited_attributes_view.png
>
> Numerous people have spotted that we lacked such a view, and I  
> think its
> presence goes some way to demystify what goes on to hook up power pins
> etc..
>
> I've added a toggle button to turn the view off, in case it  
> clutters the
> list too much. "Inherited" attributes are always below attached
> attributes in the list, and are drawn in a desensitised style. As  
> shown
> in the screen-shot, the popup context menu gives you the option to
> "promote" a given attribute.

This is a good idea, and should be in the next gschem.

It does, however, have a downside: it will tend to lead the designer  
even more easily into the trap of attaching attributes to library  
symbols in lieu of creating editing project symbols. It's the easy  
way to start, but when your project grows big, it's a disaster. This  
redesign really needs to include the "make project symbol" button.

You wouldn't spread 100 copies of the same structure declaration  
around a big C application: it would be a maintenance nightmare. So  
why should spreading 100 copies of the same attribute set around a  
big design be the only easy, transparent way to define components in  
gschem?

>
>
> For now, _all_ attributes inside the symbol are shown, including those
> which are overridden by attached attributes. I have some patches which
> form an aggregate list - where certain inherited attributes are
> discarded from the list if they are overridden, however the correct
> behaviour isn't entirely obvious.
>
> Since gEDA allows (and uses) multiple attributes with the same name
> (net=, source=, slotdef= are some examples which spring to mind), it
> isn't obvious what the rules for overriding or combining these
> attributes should be.

Classify each attribute as "singular" or "plural". Make a rule that  
"plural" attributes may not be promoted or attached to an instance.

For the future, maybe we should have a multiline form for attributes.  
A singular version of source= might look like:

source=
foo.sch
bar.sch

Then an attached singular source= attribute could override all  
source= attributes in the symbol.

net= is a funny case, because it's really singular, one per pinseq.

>
> The code which handles these attributes each has a specific search  
> order
> and rules for how they are processed, so it seems that we can't  
> produce
> a simple "effective attributes list" for the component instance -  
> as has
> been suggested in the past.
>
> It is tempting to try and figure out a rule-set though. As in the
> screenshot, it is nice not to see the "refdes=U?", "slot=1" etc..
> attributes from inside the symbol when you already have a promoted
> version.
>
> My present rule-set (which is still broken for net= attributes), is to
> skip over any inherited / in-symbol attributes where there is exactly
> one attribute with that name inside the symbol, and one with that name
> attached.
>
> (If you had multiple attributes inside the symbol, it wouldn't be  
> clear
> which overrode which - you would either have to include, or skip _all_
> in-symbol attributes with that name).
>
>
> Comments welcome.
>
> 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-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




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