Mail Archives: geda-help/2013/06/28/13:03:38
On Jun 28, 2013, at 6:15 AM, Anees Rehman wrote:
> It is unfortunate that many open source projects lack good
> documentation.
Ten years ago, the gEDA documentation was concise and clear. But some users didn't like that. Why? Because it told them what the tools in the toolkit did, but didn't tell them how any particular task was to be accomplished. The thing about a toolkit is that it's flexible: there are lots of ways to structure your design flow. No one way fits all kinds of projects.
Consider a dual opamp. How many ways are there to express it in gschem?
1. A single symbol with all package pins.
2. A slotted symbol with invisible power bins.
3. A slotted symbol with explicit power pins.
4. A slotted symbol with no power pins plus a power symbol.
5. Two different symbols.
6. Three different symbols.
7. A slotted symbol with no power pins, using tabulated power connections merged in via pins2gsch or some similar script.
I can think of other, less sane ways, and I'm sure others can think of ways I missed.
Which way is "best"? Well it depends on what you're designing, how your mind works, what will be least confusing to those who might read the schematic, etc. There isn't a unique correct answer.
But, users want cookbooks. So, our various contributors write little tutorials on how to do various things. Unfortunately, everybody's flow is a little different. Small project approaches don't scale well to big projects, while big project fussiness gets in the way of small projects. Different people hold strong, incompatible views of how schematics should be structured. The power of the toolkit approach is that it can accommodate all this diversity reasonably well. But that requires that users take some initiative, learn the capabilities of the tools, and expect that the cookbook tutorials will need some interpretation to work in their own flow.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -