DJ Delorie wrote: > IIRC there are a few proposals and/or active solutions in play: > > * Standard library is light, users heavyify them (we need a better > verb for that ;) into a project-specific (or even site-global) heavy > symbol library. > > * Standard library is heavy, users either use those as-is or modify > them to alternate heavy symbols. > > * Standard library is light, the tools automatically heavyify them > based on some database somewhere (both static and dynamic > conversions have been seen/suggested). > > * Standard library is some mix of heavy/light. I think this is what > we have now, although not ideally implemented.
My proposal to tackle many of the library related issues is the notion of packages. These would be data structures that can contain all information relevant to an entity us humans like to build electronics from. Specifically, they may contain * symbols * footprints * simulation models * data sheets * acquisition information. * comments Note, the plural. Symbols may be alternative, or grouped. All content may be embedded or a link. Both have their specific strengths and it is up to the designer of the lib to choose. There may even be a combined embedded and linked mode. Use a link as a reference but keep a local copy for fall-back. If the reference diverges from the local copy, ask the user what to do -- update or switch to pure embedded mode. To the environment, a package can be a file or an entry in a data base. In schematics and in layouts it may be referred to with a unique name, just like symbols are currently referred to. In addition, the entry in the schematic file would tell which of the symbols, footprints, or whatever this instance uses. There would be a GUI dialog to view the contents of a package and choose from them. Of course, it would also be possible to override and enter completely new for this instance only. Much like we can do now in the attribute editor. Packages and pure symbols could be mixed transparently. Where and how to look for them would be configured in gafrc, just like we do now. So the fraction of data base lovers would be catered as well as those, who are in favor of files. They could use and share the same packages. The notion of packages can be seen as a means to isolate dependencies. Pins in symbols must match pins in footprints. Simulation models are specific to components. Packages provide a way to keep comments, notes and all kinds of meta data attached. > * It should be easy to go from a light symbol to a heavy one, so that > users can add, say, a generic resistor to a schematic and later > allocate a specific part to it. There may be a "no defaults" mode on insertion of a package. If you want to set the specifics later, click on the symbol and choose. How specific or a package is by default would be a design decision of the library author. --<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user