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

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Sun, 2009-05-31 at 17:38 +0200, Stefan Salewski wrote:
> On Sun, 2009-05-31 at 15:10 +0100, 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
> > 
> 
> Fine.
> 
> Is there a plan to modify the general concept of attribute handling?

No, no plans to do that.

Bear in mind that most places which read attributes and do something
with them already scan the attributes in a particular order - thus the
overriding of symbol specific attributes does work (for most cases).

> See
> 
> http://archives.seul.org/geda/user/Apr-2009/msg00247.html

I saw that, yes.. unfortunately our file-format isn't expressive enough
to allow it, and it wouldn't be an easy change to make. I have been
tempted to make the internal view look something like that though, but
we'd still be constrained by what we can save and read from files.


Given a blank canvas, my personal preference would be that as an
internal representation, attributes are simply name=value pairs without
any coordinates or other graphical representation.

The text you see on the schematic would be an entity without its own
text, but instead reference the logical attribute. If this entity lived
inside the symbol, it would not be movable (like any other part of the
symbol), but it would always display the final attribute value - if an
attached attribute were added in the schematic file, the text displayed
by the symbol would change to match.

I'd imagine wanting to add new primitives which allow additional
attribute display entities to be created within the schematic, and have
them attached to / move with the symbol as our attributes do currently.

Unfortunately, the fact that we allow multiple "name=value" attributes
with the same name makes things extremely complex. We can't uniquely key
an association between attribute and view based on the attribute name.


With care though, this internal representation could be mapped onto the
limitations of our current file-format, so long as we make up
coordinates for all attributes - whether hidden or not. The link between
attribute and view would be made because each attribute line in the file
specified both the attribute, and the coordinates its view is placed.



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