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

[Stuart Brorson]

Thank you for your e-mail and thoughts!  I am very glad to hear that
the folks at Cambridge are interested in developing gEDA beyond its
current state!

I have a few random comments, but no overarching point to make.
Therefore, my comments:

*  Personally, I am very open to any and all code improvements you
wish to make.  I'd bet that Ales & the other developers are too, but
they should speak for themselves.

*  One reason gEDA developement is slow nowadays is that we developers
are all working professional engineers and have many
responsibilities other than gEDA.  Personally, I am holding down a
full-time day job as well as a nighttime consulting gig.  Others, too,
are busy with their professional & personal lives.  Therefore,
precious little time remains for gEDA hacking.  Accordingly, getting
fresh blood into the project would be a very good thing.  I am glad to
hear that you might contribute in this way.

*  We will hold a code sprint on Saturday July 20.  You can reach a
large number of us then (via IRC or in person at the code sprint
location).  If you have your ideas formulated & documented by then,
they can be discussed and implemented/tested/etc at that time.
Details about this are to be announced soon. 

*  As for attribute management, your ideas about default attributes &
the ability to override them sound fine, but will require work.  At
present, gattrib is meant to handle attribute management, but 
may require some code clean-up and feature extensions.   In general,
heavy symbols are deprecated, but mostly because they require
intervention and maintainence.  Maintainence is something we don't
have lots of time for, due to the above considerations.  Therefore, we
have encouraged users to use light symbols as much as possible, and do
their own maintainence and QC.  Again, the idea is that gattrib is
supposed to make that easy.  Any changes you make should either
require little maintainence from us (or anybody else), or you should
be prepared to participate in maintainence yourselves. 

*  Replacing the project manager is a good thing; we have discussed
doing this internally for about one year but haven't done it due to
time constraints.  Personally, I think that any new project manager
should be written in Python since its job is largely to replace the
CLI, issue system commands, process text files, etc.  These are tasks
whihc call out for a high-level language.  C is not well
suited for this kind of thing since C is so low level.  C++ is
possible, but again involves the pitfalls of C, viz memory leaks,
etc. and also requires learning yet another API.  

Please do keep in mind that gEDA is a GTK based project, to any
GUI widget set you choose should use GTK only -- no KDE or Gnome since
they introduce additinal dependencies which bedevil installation.  I
suppose WxGTK is OK since GSpiceUI already uses it, but even that
presents a maintainence issue since WxGTK is often not included on
some Linux distributions.  Anybody who disagrees with me on this is
automatically volunteering to field support questions from users
having WxGTK problems with the gEDA CD, so think twice before you 
post!  :-) 

*  On the subject of the project manager: If you are going to re-use
another project, that's great!  My only suggestion is to take their
library and source files and incorporate them into your project.
Don't try to link against their .so, since that introduces yet another
dependency into the project, and also exposes you to the maintainence
problems associated with keeping your code up to date as their API
changes.  We are currently experinecing this problem with GTK, whose
API has shifted under us subtly, leading to all kinds of bugs.

*  Backanno is highly desirable.  This is an architectural question
which Dan McMahill has thought about a lot.  Perhaps you could
communicate with him privately about some ideas to acheive this?

*  Finally, another long-standing feature request for gEDA is
hierarchical busses.  Currently, busses are nothing more than
graphical annotations, and don't work across hierarchy.  Fixing this
involves architectural changes to gnetlist, which has again been
discussed at length.  Take a look at the gnetlist  source and my .pdf
drawing of libgeda's datastructures when you think about taking up
this project.

If you wish to communicate in person telephonically, please contact me
off list: sdb (AT) cloud9 (DOT) net and I can set up a conference call
with a few developers to speak to you in person.  

Cheers,

Stuart




> 
> 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
> 
> _______________________________________________
> geda-dev mailing list
> geda-dev at moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
>