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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
