On Dec 13, 2008, at 5:54 PM, Kai-Martin Knaak wrote: > On Fri, 12 Dec 2008 21:18:41 -0700, John Doty wrote: > >>> Like it or not, there are other people to whom the absence of a GUI >>> work-flow is a complete show-stopper. >> >> Yes, but I bet that most have *different* requirements for GUI >> workflow. >> So, given 100 such people, a *particular* GUI workflow would serve >> maybe >> 5 of them. > > The absence of a GUI workflow will serve none. People are much more > flexible than your argument assumes. Also, there are no 100 > incompatible > requirements to printing.
For more than a single page, yes there are. How do you put the pages together? Schematics are hardly complete documentation: what else goes in there? > > >>> As it happens, some of my customers are members of this group. As a >>> consequence, I am forced to do eagle when working with/for them :-| >> >> And this is bad why? > > Because maintaining two local libs and stay trained in two ECAD > applications adds unnecessarily to my workload. So what brings you to gEDA? Clearly Eagle is your preference. > > >>> Simple: The batch config creation dialog contains a button "Add >>> other >>> document". >> >> How does it know how to *create* the other document? > > Duncan asked for an intuitive infrastructure for printing. We have that for single sheets. Full documents need more capability, and make is an excellent tool. > Not for > creation of other documents, not for preparing a cup of tea either. > > >> What if the schematic is to be included in, say, a TeX document? > > Edit the geda created makefile to include latex clauses. If you don't > like the general structure of the geda created makefile, roll your own > from scratch. Just like you do now. Please don't argue like your > favorite > way of working is going to be harmed. > > >>> So what? Your freedom to write a script from scratch is not >>> affected in >>> any way by the GUI generated script. >> >> Why are GUI tools generally so hard to script, then? > > Errm, I propose a GUI way to produce a script. Not the other way > around. That hardly ever works well. > > >>> Please don't discourage efforts to >>> improve other work-flows than the ones you prefer. >> >> That's *exactly* what I'm saying. > > Still, you do exactly this: Whenever somebody calls for > improvements of > the GUI you step up and suggest to adopt your favorite mode of working > with geda instead. Adding complexity might reasonably be considered damage rather than an improvement. > > >> I am afraid any *specific* GUI will either be too inflexible for most >> flows, too complex to be comprehensible. In either case, it will >> waste >> the user's time by forcing extra point and click operations where >> actions should be automatic. > > Ouups, you did it again: Not accept other peoples needs and discourage > efforts to improve their workflow. I doubt you can serve their needs in this way. Unnavigable menus producing incomprehensible scripts seem a more likely result. You are welcome to try to prove me wrong. You are not welcome to complain that nobody else has tried. > > >> Graphic tasks need GUI's. Forcing non-graphical tasks into a GUI >> framework is inefficient and inflexible. A low productivity approach. > > Not true in the general case. Scripting of seldom needed tasks is > inefficient. On the contrary, I find it very handy to have scripted many things over the years. Sometimes two years later I have to redo something: having a script is enormously better than having to figure it out all over again. > BTW, schematic capture is not inherently a graphical task. A > schematic is just a GUI tool to produce a netlist. But textual netlists tend not to be comprehensible. Usually a graphical representation is better. But there's no one way that is best: for some cases, e.g. connector pinouts, text is better. But for an amplifier, a diagram is better. Use the right tool to make the right representation for the job. Despite an enormous amount of effort by computer scientists, graphics have not generally proven an effective representation for automated procedures. > > >> It's not a matter of which kind of tool is better, it's a matter of >> using the right kind of tool for each part of the job. > > Printing all pages in a hierarchy should not require a separate tool. "A program should do one thing well" - Brian Kernighan This means that programs that need not be integrated should not be integrated. It's the key to making it possible to use the computer to automate your work. > > ---<(kaimartin)>--- > -- > Kai-Martin Knaak > http://lilalaser.de/blog > > > > _______________________________________________ > geda-dev mailing list > geda-dev@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev > John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
