> It seems to me you're arguing for a plugin mechanism for gnetlist, > too.
Perhaps, or something more global. I.e. it would be nice if you *could* query these extra databases from within gschem or gattrib, for example, to see what the inferred attributes are, or to see what the options are so you can explicitly set something. For example, if you specify a 1k resistor, it may give you a choice of 0603 or 0805 footprints. By choosing one of those, you've helped direct gnetlist towards a specific part and the extra attributes that go with it. So the two types of "plug-ins" would answer these questions: 1. Given the attributes the user has already specified, what other attributes may be set and to what values? 2. Given a set of specified attributes, what other attributes are needed, and can we infer the values of those attributes, either by process of elimination or by project-specific defaults or rules? The second needs the first, of course, but both should be available to more than just gnetlist. > Right now, gnetlist merges netlists and attributes extracted > from gschem schematics, and then passes that information to a "back > end". But why not allow multiple front ends? Merge information from > multiple formats into the data structures. Then allow "filters" to > work it over: that's where one might implement a "requirement to BOM" > process. Finally, pass that to the back end as now. Certainly a good idea, except that it doesn't offer a way to feed-back to gschem for things that the user *must* (in their opinion) select. For example, what resistor values are available? In what tolerances? If you pick a 10uF capacitor at 10v, what's the smallest package it comes in? Like I've said before, the schematic is more than topology - it's design. Some attributes are intrinsic to the design, like resistor/capacitor values, and should (according to some folks at least) be included with the schematic. The extra database contains (or could contain) all this information. It's up to the user to specify *enough* attributes to uniquely identify a specific physical part (in the pcb case at least), or in combination with a BOM tool or preferences ruleset, at least be able to pick something appropriate. However, IMHO the user needs access to these attribute options in gschem. They may not always use gschem for this; there's no reason why the choices or rulesets can't go elsewhere, but a goodly chunk of our userspace will want a way to choose such things right in gschem. Especially if one of the attributes is "value" :-) The key to heavification is that some of the inferred attributes include the pin name-to-number mapping. This lets you use really light symbols without the "transistor problem" we currently have. But even then, users may want to direct this slotting from within gschem. _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
