gEDA-dev: [Re: is all EDA as bad as gEDA/pcb?]

[DJ Delorie <dj-at-NOSPAMdelorie_dot_com>]

Russ is a college buddy of mine, and we've been conversing on his "new
gEDA user" perspective as he tries to learn the tools.  He gave me
permission to pass this particular email along, but keep in mind it
was written for my sympathetic ear, hence it may sound "grumpy".

------- Start of forwarded message -------
From: Russ Nelson
Date: Sat, 8 Dec 2007 18:03:35 -0500
To: DJ Delorie <dj@delorie.com>
Subject: Re: is all EDA as bad as gEDA/pcb?

DJ Delorie writes:
 > Yes, there is a lot we could do.  No, we don't have a lot of resources
 > to do it with.  Yes, money would help - some.  If it's enough to
 > replace someone's full time job (~100k/year after expenses), it would
 > help more.  More people would be better.  More feedback from people
 > like you (newbies) would be good too (like that long email you deleted
 > ;).  I know it's hard to quantify "it sucks" into specific suggestions
 > for improvements, and I know the "best" improvements are the ones that
 > will cost us the most.  We keep trying anyway, but it's slow.

Suggestion: decide on ONE library format across all of gEDA.  If you
can't decide, then get rid of them both and replace them by something
better.  IMHO, the components should be specified by a Python program.
That way, if you want programmatically-generated devices, the Python
program pops up a window that says "how many pins by how many pins" or
"what size resistor footprint do you want?"  and "Do you want to
default to that size everywhere in this project?"

In a perfect world, the part vendors would write the part description,
but we've already had that discussion.

Suggestion: hand beginners a beginner-level library, which includes
thru-hole 1/4 watt resistors, diodes, ceramic disk caps, tantalum
caps, electrolytic caps, LEDs, 8-pin dips (and 14, 16, 20, and 40),
common PCB-mounted switches, headers, and power supply connectors.
Maybe a DB-9 connector, but I wouldn't encourage my worst enemy to use
RS-232.  Nobody deserves that kind of pain.

Suggestion: when somebody creates a component and saves it, ask them
if they want to contribute that component.  Or ... make component
creation an inherently on-line and shared process.  E.g. create a web
form for components wherein people link to some vendor's store, and
the web form scrapes the store to get the information about the device
to create the footprint (may not be practical.)

Suggestion: when somebody starts up pcb, ask them how many layers they
plan to use.  Having fourteen layers shown when you're producing a PCB
at home, is no help at all.

Suggestion: use reasonable defaults, e.g. 100 mils.

Suggestion: PCB should understand metallic connections, and try to
preserve them.  If I put down a component and connect it to another
component using a line, and them move one of the components, the line
should follow using the same "preserve straights and 45's as
necessary" algorithm that the line was placed with..  When would that
ever be the wrong thing to do?

GTK Suggestion: EITHER consume the right mouse button with scrolling
OR auto-scroll, but don't do both.  Preferably, don't auto-scroll,
because as it's currently implemented, if you're zoomed in,
auto-scrolling instantly scrolls you half-way across the page.  Some
tools always auto-scroll; some don't.

GTK Suggestion: When you're depositing components, you get a
wire-frame component.  That's fine, but when you leave the canvas, the
wire-frame should disappear.  As it's currently implemented, the
wire-frame is still drawn.  If you go to the library and select a
different component to deposit, the current wire-frame remains
visible.  It's obviously being drawn using XOR and somebody forgot to
do an extra XOR on exit.

GTK Suggestion: don't use the same "selected" color as "pressed"
color.  It's WAY confusing to push a button (to turn a layer on and
off) and see no change at all.  Yes, the thin gray border around the
color changes from white to grey, but I only noticed it right now
because I played with it while writing about it.

Suggestion: do some usability studies.  This involves putting a EE in
front of PCB, and videotaping them, their screen and their face.  This
is amazingly painful to watch, but it's also amazingly educational.
"Gee, I didn't know $X was so hard."  Clarkson has a usability lab,
last I knew.

Suggestion: call it something other than "pcb".  A google search for
"pcb" is completely useless.

 > Meanwhile, I'm at least rewriting the pcb documentation.  It will take
 > time, because good documentation is hard to write, but I've got a
 > start here: http://www.delorie.com/pcb/docs/gs/

I'm sure this will be a good thing, but IMHO software that needs
documentation is software that needs fixing.

BTW, installing pre-built packages for Ubuntu and Debian should be
identical, and is simply a matter of doing this:
    sudo apt-get install pcb geda

 > Also, if you read the mailing list archives, you'll see that even
 > among the regular gEDA users, we still complain about things we wish
 > we could get around to adding :-)

I'm sure, but I'd start by throwing the whole thing out.  Schematic
capture and PCB design need to operate on the same representation of a
circuit using a single description of component including schematic
symbol, pinouts, pspice model, and footprint.  I ought to be able to
fire up the design program, throw a resistor and capacitor into a
circuit along with a power supply and ground.  Then I should be able
open up the simulation view, right-click on the component or wire and
see the current or voltage on that component over time.  Then I should
be able to open up the PCB view, and see a reasonable layout.  Then I
should be able to open up the BOM view and see which vendors have
those parts in stock, who can make the PCB, and how much it all costs.

Who would pay for that?  The vendors who get their purchasing
information into the program.  It works for Eagle, and they're just a
PCB house.

------- End of forwarded message -------


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