kicad-developers team mailing list archive

[Patrick Maupin <pmaupin@...>]

(Warning: lengthy post)

I have been using eeschema for about two weeks now, and wanted to
share my initial impressions while they are still reasonably fresh.

First off, I want to congratulate the team -- Jean-Pierre, Dick,
Wayne, Ivan, and numerous others -- for all their hard work on
this. I looked at Kicad about three years ago and deemed it
interesting, but not (at that time, for me personally) worth
investing any time learning. It's amazing what a little time
can do -- you guys are awesome! The program has been rock-solid
for me, all the required functionality is there, a quick scan
of the mailing lists shows that user reports of actual bugs are
dealt with expeditiously, and you are starting to add some
seriously decorative icing on the cake.

Aside from the fact that eeschema was fast, never crashed, and
offered very few negative surprises, one of the best features,
from my perspective, is the well-documented ASCII file formats.
The documentation may be a little behind the times, what with
all the new text options and bezier curves and what-not, but
it's still pretty darn good, and it allowed me to script the
generation of basic library components extremely easily,
eliminating one of the most tedious, error-prone steps of
schematic capture. Also, being able to dump ASCII schematics
and libraries into a subversion repository is golden.

I'm going to offer a laundry list of some things in eeschema that
did not work as I would have expected, but I may not be a typical
user. I develop a lot of boards, but for the complicated ones,
I always have someone else do the schematic capture and layout,
and for the simple, low-volume ones I have historically used the
expresspcb layout package, WITHOUT ever doing a schematic. (I
have a love-hate relationship with expresspcb -- it's a great
program and service for simple, small-volume boards, but their
paranoia that someone might rip them off by using their software
with someone else's board house leads them into many unfriendly
design decisions, starting with the encrypted file format.)

So, take whatever value you can from the list below, but please
don't take any offense -- I know some of these items are personal
preference, and even that my preference may change after a few
more weeks with the program. As I tried to explain, I am by no
means a schematic capture power user -- this is the first time
I have tried to do this seriously in a very long time. For what
it is worth, I am nominally using the subversion head (currently
R1965), compiled from source on ubuntu jaunty.

1) Not everything on the toolbar is available from the menu. I
know that you guys are already looking at ways to fix some of
these UI issues, but I thought I would mention this anyway.
For some reason (maybe partly because I'm old and blind :) icons
don't mean much to me. I never look at the toolbar until I'm
trying to see if there is a way to speed up an operation I
already know how to do. Even then, my first preference for
speed up is to use the accelerator key shown in the menu.

2) The bounding-box around components used for determination
of whether they are part of a mouse selection is bigger than
expected. It apparently encompasses the pins, not just the
component body. This means that, if you try to grab a few
things that are near the corner of a large rectangular part,
you have to switch to component-at-a-time selection and
movement.

3) I would prefer that the default be drag rather than
move. I very seldom am doing a move that could not also
be done with a drag, but the opposite is not true. Also,
if the parts stayed selected after the initial drag (until
you selected something not part of the current selection),
then you could modify the selection by holding down control
and clicking (once you no longer need the control key to
indicate that you are dragging and not moving).

4) If I have started a move, drag, or copy which I do not
wish to complete (perhaps because I meant to do a drag
instead of a move), while ESC exits the mode fine, I am
surprised that CTL-Z does not do the same thing. Instead,
with CTL-Z, you are left in the mode, doing what you started,
but other things you have done in the past are undone. The
first time this happened, I was surprised enough that I must
have hit CTL-Z 4 or 5 times before I realized it wasn't a
problem with my keyboard.

5) After I have screwed up as detailed in (4), if it is not
too much trouble to have multiple accelerator keys bound to
a single action, it would be great to have CTL-SHIFT-Z bound
to REDO, because that is what I happen to reach for first.

6) The ESC key does not dismiss the component selection dialog.
This surprise is particularly disconcerting right after I have
been surprised by only needing to single click on an item in
the history list in the dialog -- the combination of my
mistaken double-click with ESC not working means that I just
placed an extra compent, and I need to spend extra time and
effort to visually track down the cancel button and then nail
it with the mouse.

7) I know this one is a preference item, which if supported,
would probably require a user-option. Personally, I absolutely
hate when the system automagically helps me out by moving the
mouse pointer (e.g. on a zoom). Maybe my eye-hand coordination
isn't good enough, but I *always* visually lose track of the
mouse pointer when that happens. It also means that eventually
I need to pick my mouse up and manually reposition it on the
desk (kind of like untangling a phone cord). It also means that
if I want to get my bearings on the schematic by doing a quick
zoom out and back in using the mouse wheel, I don't get back to
exactly the state I was in before I zoomed out. I would prefer
an option to work like expresspcb -- the mouse stays put, and
the pixel on the schematic directly under the mouse also stays
put (the mouse is the focal point of the zoom).

8) It would be great if the "edit field" dialog box had the
controls to be able to change the style and size. I know that
is some code duplication, but then again, the field name itself
can be edited in the main component dialog, so obviously some
duplication is allowed in the name of convenience :)

9) If (8) is done, it would also be great if you could open the
"edit field" document on a power port component, and just have
the actual name greyed out, but be able to set the size and style.

10) A "plot to PDF" option that generated searchable PDFs would be
really, really great.

11) I would like a really simple DRC option to just look for what
I call "danglies". On the complicated boards I have done in the
past, I have always scripted a board-specific DRC, based on the
netlist. I typically view the DRC available in the schematic
capture program as too limited to be of much interest. For
example, calling a pin a "power" pin does not indicate that the
part will be completely fried if the pin is connected to +5V instead
of +1.8V. So, I view the exercise of telling the capture program
"this is a power pin" to be wasted effort that could be directed
towards a REAL DRC. For this reason, all I really want from the
capture program is a basic sanity check that there are no single-pin
nets, before I save the file and do a real DRC on it.

12) In the pic_programmer and flat_hierarchy demos, the 7805 regulator
is not connected properly. This maybe looks like a problem Dick was
reporting awhile back with some of his components moving -- obviously
it was correct at some point.

Please do not construe this email as me whining or asking anybody to
do any extra free work on top of what they are already doing. I sent
this in the spirit that perhaps a set of fresh eyes can help give a
different perspective.

I am a developer (though not incredibly proficient in C++ or
GUI programming), so if any of these bother me enough, I might
even attempt to submit a patch myself at some point, after re-reading
the guidelines and running the decrustificator.

Best regards,
Patrick Maupin
Austin, Texas