On Aug 24, 2011, at 2:46 PM, John Hudak wrote: Rudeness snipped.
> The > philosophy of gEDA has already been established. Kind of. But part of the misconception you have is that gEDA (as currently defined) has a coherent philosophy. gEDA once referred only to gschem, gnetlist, and associated tools. "pcb" is an older program, which I believe only came under the gEDA tent after gschem replaced xcircuit as the tool of choice for schematic capture by pcb users. I think this is very confusing to new users: pcb and the gschem/gnetlist/gattrib/... kit play well together, but they are not integrated. They represent different design philosophies, and cannot be integrated without damage. A Jeep pulling a trailer is more flexible transportation than an integrated RV. I think that a great deal of confusion and strife would be avoided if the core developers would separate the pcb and gEDA projects. > What is more > important is that the tool suite *flawlessly* supports a small subset > of generally accepted design-fabrication paradigms, eg workflow from > schematic to completed & populated board, and a subset of potential > offshoot efforts such as circuit simulation, head modeling,symbol > creation and package creation and management, etc. > My premise is that if you put 100 design engineers in a room who have > done circuit design to board fab and ask them to produce a scenario of > their work flow, at least 40% of them would have a common scenario. Based on the wildly different notions people on this forum have for what the common scenarios are, I doubt it. The failure of efforts by vocal advocates of the "common scenarios" point of view to create a coherent symbol library for the "most common scenarios" is evidence, too. But I would also assert that gEDA is, by its nature, the toolkit of choice for all those uncommon scenarios. You would probably be somewhat happier with KiCad (although I doubt you'd be happy with anything). > If someone buys into a certain philosophy and the tool implementation > causes them pain, they will search for less painless approaches and > adapting ones development scenario is much easier than trying to > understand and patching someone bogus code. I think it used to be easier to learn gEDA when we *didn't* have all the tutorial stuff, just concise reference documentation. It's easier to learn to fish than to have to beg for every meal. One problem with the tutorials is that there are lots of paths you can use, and each tutorial applies to a subset. > Another point is don't stick ones head in the sand and start slinging > code so that the additions 'do something'....Consider 'the other > religion' and the possibility that one might want to import a schematic > developed in kicad, Altrum, orcad or whatever because PCB is the > sexiest thing on earth. Yep, that would be nice. The problem is that import is hard without support from the upstream tool. The secret of the (multiple) ways to get a design from gschem to pcb is gnetlist, which is operating behind the scenes even if you're not using it explicitly. > One also needs to consider outflow of a design > from gEDA to whatever. This is gEDA's greatest strength. Type "gnetlist -g help" and/or "man gnetlist". > Make a road map, have a plan, follow the plan and have at it. That's the top-down approach. It has the advantage that it gets you to a well-defined destination efficiently. But if you want to go anywhere else in the future, it's trouble. Bottom-up design is more appropriate if you want unlimited horizons. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
