I think what a GUI does is no different than what Make does - it lets you encapsulate complex operations into simpler ones. When a user clicks on "run simulation", they don't care how many steps it takes to do that, they just want their simulation. When you run "make sim" to run your simulation, you don't care what the Makefile does, only that it does it.
With that point of view, look at your argument wrt your flow: This is where we disagree. The Makefile needs to make the data easy to manage, but at the same time it needs to *reveal* its machinations. If it hides everything, the user winds up either: 1. stuck with the Makefile, unable to use the toolkit as a kit, or 2. having to penetrate the Makefile code to figure out how to use the kit. (er, as an example, I still don't know how to rebuild just one subdirectory of the Linux Kernel - I always run a full make from the top, because that's the only thing I've figured out so far) The solution to these problems is not "transparent tools", it's "better documentation". I've seen the Makefiles ISE spits out, that doesn't tell me how the tools work. Now, I don't think the GUI should hide information for the sake of being obscure. I think the GUI should hide information because the user already has enough to worry about. We get a lot of users complaining about "too many clicks" or "why can't I do that in the gui". They use a GUI because they want to work on their design, not learn how to use our tools. Many of them don't even know a shell window exists. Consider the pcbfwd netlister (File->Import in PCB). It's scriptable. You could run gnetlist manually. You can use that in a Makefile to update a layout. But the *only* feedback (er, non-bug-report type) I get about it is "Wow! I can update my layout with one button!". _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user