Re: gEDA-user: Ben mode feature request

[John Doty <jpd@xxxxxxxxx>]

On Nov 1, 2010, at 12:32 AM, Vanessa Ezekowitz wrote:

> On Sun, 31 Oct 2010 20:39:40 -0600
> John Doty <jpd@xxxxxxxxx> wrote:
> 
>> 
>> On Oct 31, 2010, at 2:31 PM, Markus Hitter wrote:
>> 
>>> Then, there are many people which know "cp xxx yyy", but prefer to avoid
>>> it anyways. You want to catch these.
>> 
>> You don't want to dumb down the toolkit [...] gEDA is the toolkit for
>> *experts* doing *great* things *now*. Let's not lose that. One size does
>> not fit all here.
> 
> Ok... Sorry, John, but I have to stop you right there, as you are completely missing the point.
> 
> To clarify Markus' example somewhat:  I don't want to have to fire up a terminal every time I want to copy some random file to/from a thumbdrive, memory card, etc.  Sometimes, I'd rather just plug the damn thing in and let a file manager pop up so that I can handle it from there.  It isn't because I can't, it's because I don't *want* to.

What you want doesn't matter. What the *job* needs is the thing that matters.

> 
> On the other hand, I use a simple script that uses rsync to back up a few important partitions and directories and take logs of the activity, which is best run from a command line, because for that particular case, it is the right tool for the job.

Indeed. But in fact, I bet if you did a time and motion study you'd find that typing commands is much faster than point and click. Point and click is a seductive time waster *except* for inherently graphical parts of the job.

> 
> <rant mode="on">
> 
> To bring this back into context, I am by no means an expert in electronics or programming, but I am reasonably good at the few things I do with gEDA and PCB, at least so say the other folks who are in my particular field.  Your implication here is that these tools are and should be reserved only for experts,

Absolutely not. However, there should exist tools that serve needs of experts. There are lots of tools out there that sacrifice productivity and flexibility for user comfort. I am tremendously grateful to Ales for creating a toolkit that can do what I *need* rather than what some marketer decided I would want.

> which is akin to saying that everyone else should basically just uninstall their copies of these programs and get out of the way, even if the intent is to help improve the project. 

I have a Jeep with a manual transmission and manual transfer case. Most drivers today would consider an automatic transmission and "all wheel drive" an "improvement". But the manual controls enable me to drive through nasty conditions where more automatic vehicles get stuck (getting up my driveway is often the worst problem). I live high in the mountains, so this is important to me. It is a good thing that that the comfort of the majority did not dictate the design of this vehicle.

>  Um, no.
> 
> In the old days it was common, if not *expected*, for a person to first draw his or her schematic on paper  and then lay out a board on one or another physical media prior to etching.  Hell some people *still* do it this way if it is more convenient to do so.  What we didn't have back then was an easy way to do circuit simulation - you did your truth tables and math on paper, built a prototype on plugboard, and then prayed that it passed the initial smoke test when you switched it on.
> 
> Now we have easy to use systems to allow one to design a schematic and ensure that the board created from it is at least electrically identical, so far as the copper is concerned anyway.  We just need the equivalent for circuit simulation.

With gEDA, we already have that for chip design. I have the working silicon to prove it. And this is a place where gEDA's superior scriptability really shines: it's a *massive* waste of time to run a comprehensive series of simulations manually after changing something.

>  Some reasonably good GUI tools already exist for this (Xcircuit, QUCS), they're just not part of (or compatible with) the gEDA suite.

The most difficult problem here is outside of our control: obtaining models compatible with whatever simulator you prefer. But on my gedasymbols page you'll find some *simple* opamp models, and a bunch of symbols for my friend Professor Ikeda's "Openip" library of models for mixed-signal VLSI design. I know somebody who has used the Openip symbols and models as an aid for learning logic design. You don't, of course, actually need to go all of the way to silicon.

The overloading of pinseq= is also troublesome for simulating slotted components, but fixing this requires no changes to the gEDA core: it's implemented in the spice and spice-sdb back ends.

And one really cool thing here is that a gnetlist back end can generate symbolic equations for a circuit, so you can do things like find the ratio of RC time constants that give critical damping. Again, that's enormously more productive than tweaking a simulation. Where's the "find critical damping condition" button on your favorite GUI app?

> 
> Just because one is doing this on a computer instead of paper does NOT mean one should be forced to use the command line to do it.

I can't afford to be forced into a low productivity mode of operation.

>  Computers are supposed to make things easier for people, and allow them to be more productive; that's what they were created for.

Yes. That's exactly why GUI should be limited to jobs that really need it. It's a productivity sink.

>  If introducing a computer to a user's workflow doesn't improve his or her productivity, then either the computer is simply the wrong tool altogether, or the person responsible for the software therein is the one who is at fault.

But in your argument, you confuse comfort with productivity. For productivity, command line is *better* except for drawing. Drawing is only a small part of EDA.

>  In the commercial world, if the software were the problem, one would of course blame the admin for installing ineffective programs, or the programmer(s) for failing to understand what users really need.  I hesitate to make that claim against gEDA, since it is a *very* effective tool set, and the need for improvement is clearly recognized (or we wouldn't be discussing this).

Yes. It is a *very* effective tool set precisely because it doesn't suffer from all of the blockages that afflict GUI tools.

> 
> The existence of a GUI does not have to preclude the use of equivalent command-line utilities.

Putting a GUI on non-graphical functions *almost always* torques the design away from effective scripting. You can claim this isn't necessarily so, but actual software designers aren't usually smart enough to avoid this trap.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user