On Dec 12, 2008, at 7:54 PM, Kai-Martin Knaak wrote: > On Fri, 12 Dec 2008 12:51:13 -0700, John Doty wrote: > >> The simplest things (page->ps and page->png) are supported well. > > Options are not remembered across sessions. There is no way to render > colored postscript. Font size in postscript output does not match the > font in the GUI. PNG output is restricted to a small set of > resolutions. > Lines are strictly one pixel wide even at resolutions that render > multi > pixel in the GUI. This leads to all kinds of artifacts representations > when rendered at anything but the "natural" resolution. > I'd call print support "basic" at best, but not "well". > > >>> Even the >>> most common tasks like PDF output of the current schematic need non- >>> trivial customization. See the wiki faq on this. >> >> What makes you think somebody else's GUI will do what *you* want >> here? > > What makes you think, the desire for PDF output is specific to me?
It isn't. But I type "make whatever.pdf", and it gets made with a minimum of machination. In simple cases, like a single sheet, the default rules in my makefile boilerplate suffice. This is much more productive than working through a complex maze of menus. > > >> I am absolutely certain that any GUI driven work-flow will be >> wrong for >> most of my (multiple, disparate) purposes. > ^^ > 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. > 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? Perhaps Eagle is inflexible and poorly scriptable? > > >>> Let the user decide which pages to print and create a customized >>> print- >>> config file from the input of the user. >> >> What if you want to include things other than schematics in the >> document? > > Simple: The batch config creation dialog contains a button "Add other > document". How does it know how to *create* the other document? What if the schematic is to be included in, say, a TeX document? That's why make is so nice... > > >> GUI-generated scripts tend to be pretty inflexible. > > 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? > Please don't discourage efforts to > improve other work-flows than the ones you prefer. That's *exactly* what I'm saying. > > >> A computer is best used to *automate* your work, > > Sure. And applications should free me from the need to reinvent the > wheel. Applications should not require me to turn my wheels by hand crank. > Common tasks like "print all pages of a hierarchy" should not > require any programming skill at all. > > >> GUI tends to get in the way of automation, especially in cases where >> different users (or even a single user like me wearing different >> hats) >> have very different needs. > > Again, please accept other peoples needs. Exactly my point. > A GUI driven work-flow is by no > means exotic but a legitimate preference. 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. > There is a reason why some > major commercial ECAD applications like protel are GUI-only. Since > altium > charges big money, they better listen to their customers needs. But they don't. They market shiny stuff to corporate apparatchiks. They don't serve the real needs of the designers in the trenches. That's what's so nice about gEDA: not shiny, but effective. > > That said, I prefer to use tools, that allow for some kind of > scripting. > Well designed applications should be capable to do both, GUI and > scripting. Come to think of it, neither schematic capture nor layout > design with pcb can be done with scripts. Graphic tasks need GUI's. Forcing non-graphical tasks into a GUI framework is inefficient and inflexible. A low productivity approach. > Thus, the algorithmic work-flow > fails due to lack of infrastructure. 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. > > > ---<(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
