> That is true. But why do we need this? Why should pcb know that the > attribute "value=LM2596" came from a database, or from manual input, > script generated?
I'm thinking of the case where an attribute is defaulted by some BOM manager because it's the only option that fits. For example, if you pick a manufacturer's part number and a preferred vendor, the vendor part number is defaulted. This is different than picking a vendor part number and letting the manufacturer be defaulted. So later when you go to update a BOM, it's less likely to be trouble if the user attempts to select conflicting attributes. I'm not sure how to resolve it, but knowing what data are "picked" and which are "defaulted" will be useful for resolving conflicts, or at least complaining to the user. If we have data A, B, and C, and the user changes A, we need to know whether to update B or C to resolve conflicts. I'm thinking of something like xfontsel, which has multiple fields which can be set to a specific value or left as a wildcard. If it's a wildcard, the drop-down menu for that field only allows the values which make sense given the other picked fields. If you can't pick what you want, you have to change some other picked fields to wildcards. For example, if I pick the adobe foundry, I can no longer choose the arial family. If I want arial, I wildcard the foundary and choose the arial family. If I then go to the foundry menu, only monotype is available. In the geda sense, "monotype" is now a defaulted value - there's only one option, but it wasn't explicitly selected by the user, so it doesn't restrict other choices. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user