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. >> 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. >> 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. 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. >> 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. > 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. > 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. BTW, schematic capture is not inherently a graphical task. A schematic is just a GUI tool to produce a netlist. > 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. ---<(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
