On Fri, Oct 23, 2009 at 4:33 PM, Peter Clifton <[email protected]> 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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
