Just on the general topic of user interface design for this sort of thing:
The arguments of UI streamlining can go two ways. You can say "we're not interested in making our software accessible by the general public, we want to focus on developing for power users that are already familiar with the software, since they're the ones that will benefit most from improvement". Or you can say "we want our software to compete with and possibly replace the closed-source proprietary packages that are the industry standard, and so we're trying to make the transition to our package as easy as possible for someone experienced with EDA software in general, but not with gEDA specifically."
Both of these are legitimate attitudes. I, personally, adhere to the latter.
I think what Aaron was trying to get across was not "the standardized way of doing things is better than the way gschem currently works".
I think the point he was trying to make was that most software, and just about all widely-used software, has a set of standard interface operations that the user expects to work. So sure, if you've been using gEDA for a year or so and have figured out all the little tricks, you'll get used to it and maybe eventually prefer it. People are pretty adaptable. But the point of standards in the first place is to try to lower the difficulty hump preventing a novice from cranking up the software and getting to work. The user interface for a pencil and a piece of paper always works the same way; it would be extremely convenient if all software stuck to a standard UI, even if that UI isn't necessarily the best one possible. This is what makes software like Firefox and OpenOffice successful. They stuck to an already accepted UI that people were familiar with. Ultimately, more work gets done with this sort of philosophy.
One final thing I'll mention is that any time you're required to go to the command line to get something done, this is viewed as a brickwall to anything but the most experienced users of a package. The number of posts on this list with phrases like "...its nothing a little perl scripting won't fix" or "it just took a little copying and pasting in the .sch file and..." is disturbingly high. All the GUI optimization in the world won't do a thing for the learning curve and ultimate productivity, if you're required to drop to the command line at any point to get anything done.
In my opinion, the geda project manager was a step in the right direction to keeping everything in a GUI format. What would be an even better setup though, would be something that appeared to be a seemless blend of gschem and pcb. Something that did not require the user to drop to the command line and run any scripts or helper apps between gschem, pcb, and spice simulations.
Is it possible to embed gschem and pcb as tabs in a larger geda project manager? And then when selecting back and forth between gschem and pcb tabs, the backend netlist conversions take place to convert the output of one program to the input of the other? I'm a relatively competant programmer, but I have no idea how GUI stuff works, I work strictly on back end stuff and hardware programming.
Anyway, thats my take, I welcome any comments. If anyone can zero me in on something to work on along these lines, I'd be happy to get my hands dirty on the code. Oh, and sorry Aaron if I put any words in your mouth that you did not intend.
Thanks, - Jonathan Hanson Louisiana State University Department of Physics and Astronomy
