On Tue, 2006-12-12 at 11:50 -0500, Stuart Brorson wrote: > > This works because there's a huge database mapping the symbols, > > footprints, and part numbers to each other. We don't have that.
But we could put in place the architecture to allow the mapping. I don't propose we have a "database" as in PostgreSQL or anything just yet, but the logical mapping between symbolic connection names, and footprint pins should be possible. I'd see it as an interim design step, selecting a mapping. I'm not sure if the mapping has a unique name, or is made up of a name based upon the symbol, footprint, and some other text though. We could offer "mappings" (or "real parts" if you like), in gschem's symbol selection dialog, saving work during the interim step if the user wants. > True. But my point is this: Maintaining a real parts library is a > full time job. And it's not fun -- it's drudgery. Since I expect to > get paid to do drudge work, I don't think we should make any promise > that gEDA's parts library is anything more than a shell, or a large > collection of examples which might be useful to another user. That > is to say: Our current implementation places the entire burden of > maintaining the parts library on the user, and keeps it away from us > developers who do this as an unpaid hobby. I view this as "tough > love" for our users. Since we push the burden of keeping the library > onto the user, we should accordingly use a parts library mechanism > which is drop-dead simple and can be used as a basis for creating his > own parts library, which he maintains himself. I don't think anyone suggested that this architectural change would involve the developers maintaining the parts library, but it instead adds the functionality so the user can do so. Hell, if someone implements it, I'd be glad to see the back of some heavy symbols in the symbol library, so I'd be up for a session helping to convert symbols. I don't see it as an all or nothing change which would require us to re-do the whole shipped symbol library, just a gradual improvement as people contribute stuff. > I disagree. Our system is dead-nuts simple -- just edit the symbol > file to provide the corrrect pinouts (if the pre-existing sym file is > wrong), figure out the name of the footprint you need, attach it in > gschem or gattrib, then proceed to layout. A scheme where we maintain > a mapping file between symbols, pins, and footprints adds another > level of indirection which can be misconfigured, and it adds another > file which can have mistakes. I see this as more a mechanism to avoid mistakes, which like it or not do get made when using the gEDA parts library. New and experienced users alike won't always realise / remember to check symbol pinouts every time, but being forced to by the absence of a mapping, there is less potential for error. If no mapping explicitly exists, having to specify one - either in a file, or with a point-and-click GUI dialog will make the user think. I don't see how we can advocate light symbols so strongly when our shipped parts library, and entire architecture is centred around having one symbol per part - user provided or not. Peter C. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
