Oh boy am I glad y'all are having this conversation, and I hope you don't mind some comments from the peanut gallery.
On Fri, May 20, 2011 at 11:01 AM, DJ Delorie <[1]d...@delorie.com> wrote: [Subject changed to start new thread] > When I first read geda documentation, there were already references > that this had been discussed ad nauseam. Sigh, yes. It's not an easy problem to solve, and I would consider any solution a "major effort" because it touches everything from gschem to pcb to sim. No it isn't easy but for the reasons mentioned above has the potential to improve gEDA usability (ergo adoption) in significant ways. ...the ability for the user to manage their library from either gschem or pcb would be ideal. Yes please! (right click and or hotkey -> attach footprint to symbol) Bonus points for backwards compatibility, but I think that would only make things much harder for us. I'm willing to start fresh with the caveat that old designs would need to point to old libraries. In the past the desire for backwards compatibility was a stumbling block for this, but perhaps we just need to accept the breakage. I'm also willing to consider a new method for auto-generating families of footprints. I think M4 is not the preferred method for anyone anymore, despite a general disagreement about what *is* preferred :-) Put me down for intense dislike of M4. Sorry. I'm sure it's a fine choice for some, but I've never had to touch or know anything about M4 for anything else, ever. Which means that on some occasion that all I had wanted to do was make a printed circuit board; now I have to go and learn enough about M4 to make my little footprint(s). It also means that I'll probably do something wrong, or in a non-optimal way, since I'll never use it enough to achieve any sort of proficiency. tl;dr I would love an easier way to generate footprints. > If the default lib is to be changed now, then there should be some kind > of new consensus on the heavy/light issue. There are many perfectly reasonable occasions / individuals who would prefer the heavy option. It is also reasonable to say that the light option gets you the most flexibility. After years of watching this debate go nowhere, may I suggest that you must either find a way to do both, or tell some of us to bugger off. 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. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have "all" of them. Nobody needs all possible heavy symbols, and disk space is cheap. The solutions either accept a common subset of heavy symbols or defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. This is bad for so many reasons, not the least of which is that there will be so much duplicated effort spent on a very mundane task, like creating a symbol/footprint for some three-terminal regulator, or TTL logic gate or something. My own proposal (posted in the past) is here: [2]http://www.delorie.com/pcb/component-dbs.html It moves the problem out of gschem and into the netlister, which gives PCB the opportunity to be part of the process as well (the netlist can accept input from both gschem and pcb), but adds the requirement for back-annotation for those who prefer the master schematics to have that info in them. It is also an optional step in the flow, so it doesn't block other solutions (like a heavy-only library). Note that any solution should have these attributes: * 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. While text editing is technically easy, it doesn't streamline into a gui-centric flow, mor is it readily scriptable. * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This might mean a "starter" set of heavy symbols, or it might mean the GUI is streamlined for heavyifying light ones. * It should be equally easy for newbies to, say, do their first simulation. This might mean an alternate database for sim vs layout with "modes", or it might mean distinct "domains" for heavyifying so that one schematic can hold both sets of information, or it might mean storing flow-specific heavy data elsewhere and merging in the netlister. * Massively scripted flows should remain massively scriptable, while gui-centric flows should remain gui-centric. My suggestion for symbols and footprints (and maybe other / metadata). Don't ship gSchem or PCB with any. At first run, and in preferences, and in config files, give users the ability to choose their own poison. Use git to synchronize with a (set of) master symbol and or footprints, and or something else databases. Include options to use others' symbols / parts (gedasymbols, luciani, etc). Include options for users to share their own symbols via git. Create online symbol and footprint generators that create standard footprints (at least for JEDEC standard stuff) properly (according to best practices). By the way, if you guys decide to tackle a big re-write, the IPC and NIST tried to tackle this problem a few years ago. I don't know what ended up happening to their efforts, but it might be worth looking at what they did. They produced a nice little GUI thing which can be downloaded at the link: [3]http://webstds.ipc.org/viewer/Offspringviewer.htm# Many Thanks, -CN References 1. mailto:d...@delorie.com 2. http://www.delorie.com/pcb/component-dbs.html 3. http://webstds.ipc.org/viewer/Offspringviewer.htm
_______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user