On Sep 28, 2008, at 9:54 PM, Peter Clifton wrote: > I'm of the opinion that the .sch file should still end up > containing all > the required design information,
I have the opposite opinion. The "everything in the schematic" approach is a serious barrier to schematic reuse. It makes the process of choosing and and especially changing parts tedious and inefficient. > even if we use a helper app. to fill in > some of the blanks. > > The only exception to this feeling would be if the schematic stored > some > attributes suitable for keying into a database which are picked up > by a > gnetlist "back/front" end. We have this capability already. Symbol files are nice flexible containers for the database information, easy to edit graphically or textually. > This said, it would still be nice to see the > schematic cache the results of any database lookup, so they can be > distributed eaily to other parties who might not have the same > database > setup. The way I do this is that the design is a collection of files: there are often multiple top level schematics, and I use hierarchy quite a bit. Each project has a collection of project symbols that mostly start as copies of symbols from either the gEDA distribution or from a previous project. Ideally, every component symbol should be in the project collection. Then "Hs" does exactly what you need: it edits the component database for your project. The missing ingredient here is a simple one: the symbol browser should be able to automatically copy symbol files into the project's symbol repository. Right now, I find myself browsing for a symbol, getting its name, using "locate" and "cp" to get it to the project repository under a project-specific name, refreshing the symbol browser, and then browsing for and placing the symbol. This slightly inconvenient procedure saves a great deal of work later. One thing that can get in the way is gschem's default of promoting attributes like footprint. That gets in the way: the project's default footprint isn't usually a sensible schematic-level attribute. Of course, if I have a special requirement for a particular instance, it's easy to override it with an attached attribute. So What gEDA has now is tremendous flexibility. It makes more sense to me to preserve and exploit that rather than changing to a less flexible approach. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
