On Mon, 2008-09-29 at 20:55 +0900, John Doty wrote: > 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. [snip] > We have this capability already. Symbol files are nice flexible > containers for the database information, easy to edit graphically or > textually. Ok, fair enough. Heavy symbols is another way to go about things. I was talking about the possibility of using lighter symbols in the the library, then associating more specifics in the schematic. You could also attach the specifics in a "heavied up" symbol file if so desired. > > 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. If the symbols start really light, don't you find you need to have multiple resistor symbols, transistors, diodes etc.. once you've heavied them up? I'm sure it would be fairly easy to have gschem make a copy when selecting a symbol, but I wouldn't expect that the name ends up correct without user input. > 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 part "under a project-specific name" is the gotcha. You'd need a GUI or something to enter that name. > 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 I presume you turned promotion of those attributes off in your gafrc? > 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. Sure, we weren't talking about taking any of the existing flexibility away. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
