On Dec 14, 2008, at 6:49 PM, Kai-Martin Knaak wrote:
> On Sat, 13 Dec 2008 21:45:38 -0700, John Doty wrote:
>
>>> The absence of a GUI workflow will serve none.
>
>> How do you put the pages together? Schematics are hardly complete
>> documentation: what else goes in there?
>
> There are a number of legitimate reasons to output all the
> schematics of
^^^^^^^
>
> a hierarchical design. "Complete documentation" is just one of them.
Yes. So there are different requirements for different flows. Exactly
my point.
>
>
>> So what brings you to gEDA? Clearly Eagle is your preference.
>
> You're kidding, are you? Eagle can't handle hierarchical design to
> start
> with.
So Eagle is too inflexible to handle what you need. gEDA's strength
is radical flexibility. Exactly my point.
>
>
>>> 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.
>
> Duncan expressed the need to get a "multipage schematic print out from
> gschem".
And it can easily be done with makefile rules. In whatever way you
want. Depth first, breadth first, including simulation setups or not,
etc. etc. Radical flexibility.
> This is not the same as "create a full document". It is a fairly
> simple and common task.
An ill-defined one.
> Thus it is legitimate to expect the application
> to get this task done in a straight forward, intuitive way.
Not unless you can define it. And no doubt any rigorous definition
would fail in most cases. Where's that radical flexibility?
> Whip up a
> makefile, or some other script is neither intuitive nor straight
> forward.
>
>
>>> Errm, I propose a GUI way to produce a script. Not the other way
>>> around.
>>
>> That hardly ever works well.
>
> It is a _very_ common technique. The autoconf and automake prepare
> configure scripts and makefiles for many open source projects.
Not from GUI. You edit a top level script. And that script can put
things directly in the lower level scripts if needed. It's not
graphical: rules, procedures and definitions are better expressed
with text. Graphics are for geometry and topology.
A fine example of my point.
> Geda
> happens to be one of them.
Indeed. A scripted configuration process is very flexible. A fine
example of my point.
> LaTeX generates tex files. TeX generates dvi
> files. dvips generates postscript
A scripting flow. A fine example of my point.
> . Almost every web2 application is based
> on multi level generated scripts. You may call all these projects as
> misguided. I tend to see them as successful pieces of software.
>
>
>> Adding complexity might reasonably be considered damage rather
>> than an
>> improvement.
>
> FUD.
The many GUI-based *nix sysadmin tools are an example of the problem.
The GUI tools are inflexible, but editing the output files is hazardous.
>
>
>>> 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.
>
> Speculation. I can talk for myself: My need is the ability to do
> scripted
> workflow _and_ a GUI approach. I fail to see, how the lack of the
> latter
> is more flexible.
Less crud in the way. But look at examples of GUI. Word is far less
flexible than TeX, for example.
>
>
>> You are not welcome to complain that nobody else has tried.
>
> A feature request is not a complaint.
You haven't made a feature request. You have not identified what it
is you want. "Print all schematics" without a way to define what "all
schematics" are (not obvious in my more complex projects) or how they
are to be organized isn't a proper request.
But my makefile approach makes this easy, customizable for each
project. The user decides. You can even have multiple products
easily, from summary documents to things that are more comprehensive.
>
>
> ---<(kaimartin)>---
> --
> Kai-Martin Knaak
> http://lilalaser.de/blog
>
>
>
> _______________________________________________
> geda-dev mailing list
> [email protected]
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
[email protected]
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
