While I am wasting time with this mailing list when I should be working, here is how I propose to change the symbol organization. Feel free to do with this as you wish, including criticizing any of the (I'm sure many) issues with this proposal.
Symbol file ---------------- The symbol itself should just be a graphical/logical representation of the device. It shouldn't even have pin numbers, just labels for each pin. The only attributes within it should be related to the graphics: author, version, license,... There should be no knowledge of the physical device, or what it is going to be used for (i.e. pcb footprint or spice,...). On a related note, it would be good if in gschem you could select an object, click edit and change which symbol is being used, without having to cut/paste and copying over attributes. After a symbol is placed in the schematic an attribute should be specified that points to another file containing component or other info. This would be equivalent to an import/include statement. It should probably just be limited to one of these statements per object, although you could make a case (see below) for allowing multiple ones of these. Also note that when in the design process you specify this attribute would depend on your workflow. Note that a default component could be specified, but I would not suggest this. Or when a user is making their own custom parts library they can specify this. Component/metadata file ----------------------------------- This file could use the same .sym extension and be a superset of the existing format, or a new file format. It should not have any graphical constructs in it, but should essentially be a list of attributes. However, the big difference would be support for some kind of macro language, or at a minimum an if/else construct. In general, the attributes in this file should be made read-only, and NOT inherited/copied into the schematic data file, as it would make switching to a different component a pain. When the schematic is loaded, or if some design attribute is changed, the design and object attributes are first loaded, and then this component file is parsed using those attributes as input to if statements or other constructs. The result is that you get a graphical representation and a list of attributes that can be loaded into the internal data structures just like before. For example, in you schematic, you add an opamp, and add an attribute pointing to a component file for a specific quad opamp part. You also add an attribute specifying to use slot 3 to your schematic. The component file defines that if slot==3, the pin labeled as IN+ gets mapped to pin number 8,... There should also be a numslots defined in this component file to be used for design checks. Another thing you could do with this approach is define some global attributes for you schematic that help define your workflow. For example, if a global "spice" attribute is set, spice related attributes in the component file get used, while if "pcb" is defined, footprint related attributes are instead loaded. This could also be an argument for allowing multiple component/metadata files to be specified for each object in the schematic, where one component file is for pcb, one for spice,... Advantages of this approach --------------------------------------- - Would not require huge changes to the internals of the programs, as they should look essentially the same once loaded into data structures. - Should be a good migration path, as symbols that do not define the component/import attribute would be treated as before. - Should be more flexible for supporting different workflows, and hopefully allow better ways of organizing component libraries. Issues/disadvantages with this approach --------------------------------------------------------- - Would need to find/create a macro language. Order of operations, and other things would be need to be specified. Adding too many constructs to this language could make symbol creation more work, or cause incompatibilities between symbols/components created by different people. - Would still require updating parsing routines for a number of different scripts/tools. - Component files would be more complex than existing symbols. However, it would be possible to encapsulate more info/intelligence into these libraries. -Henry _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user