gEDA-dev: Improvements to the gEDA suite for educational use

[Peter Clifton]

I am currently working with a few collegues at Cambridge University
Engineering Department, evaluating open-source EDA tools for use and
integration with our undergraduate teaching program.

We are currently using the gEDA suite, including gSchem, PCB, GSpiceUI
and ng-spice / gnucap, but feel that there is still a high barrier to
entry for new users to learn these packages. We have two or three
students (including myself) intending to contribute software development
over the summer vacation to improve the usability and integration of the
suite.

The improvements we envisage may cover aspects in in package
intergration, GUI design, or general usability / functionality of the
software. Whilst EDA is traditionally a software area which requires a
long training / learning period, we believe it is possible to improve
the intuitive usability in gschem, PCB, GSpiceUI etc.

Our first intention is to develop a replacement for the now deprecated
project manager interface, were we may automate / assist students'
design workflows. If implemented well, it should be configurable for
software / site / board vendor preferences, such that component
libraries, DRC rules, drill mappings etc.. are all appropriate for the
resources available to students. (We may offer different cut-down parts
libraries for different student projects).

One idea I had for this might be to use the "Anjuta" C/C++ IDE
framework's shell and project manager, but customise for use with gEDA.
Its shell appears to offer a good API for plugging windows, widgets and
docks, whilst allowing communication between the plugins.

Whilst there is a motion from the Engineering Department to introduce
heavy weight in house parts libraries, e.g. having footprint and some
SPICE parameters pre-defined, it is clear that this isn't in keeping
with the gEDA design philosophy - and such we'd end up with the
difficult task maintaining a local parts library.

Working with Peter Brett, (who has more experience of gschem, and the
gEDA community than I do), I am pushing towards a solution where
attributes may be added, either:

1. As an interim work-flow process (e.g. with integration improvements
to gattrib), where we may introduce local defaults where approprite.

2. By introducing a heirachy / Cascading Style Sheet, type of attribute
management, we can define a local resource file which specifies that all
Resistors are 0.4" spaced, through hole footprint, or that we use 8Pin
DIP package 741 opamps etc., making our local "heavy" parts library more
a set of default attributes.

Such "defaults" could be overridden on a per-project / per-component /
per-component group basis, and without any config file, would revert to
default gEDA behaviour. (Which hopefully allows any code modification
necessary to be compatable for inclusion in gEDA).

I have some other ideas about how attributes might be  better handled,
but for brevity will keep those ideas for another email.

I have also looked at mocking up some screen-shots where component
attributes are viewed / edited using a side-panel / dock (which can be
torn off to become a floating window), and using the same style dock for
component selection and placement.

I have numerous other pages of usability improvement ideas, goals for
our project, and architectural ideas for the suite. I'm keen to see how
forward / back annotation can be facilitated (eventually), and to see if
it is possible for component attributes to be editable in the same way
from gschem, to gattrib, GSpiceUI, PCB etc.

We would be interested to hear your thoughts on this project, and where
our efforts might usefully be spent in such a way to benefit the whole
gEDA community, without ending up with a locally patched mini-fork.

I hope to type-up some of the notes I have on paper, and will be looking
to share these ideas with the gEDA community shortly.

Regards

Peter Clifton