gEDA: One step back and take a look around

[Michael McLay <mclay-at-NOSPAMnist_dot_gov>]

Stefan Petersen writes:
 > On Thu, 20 Apr 2000, Ales Hvezda wrote:
 > 
 > 
 > > I'm not sure I'm ready to require guile-gtk for gEDA, but this sure does
 > > bring up possibilities.
 > 
 > Agrees! No guile-gtk (at least not yet). The intention was more to show an
 > example on how a simple list could be used to define the menus. And that
 > you're able to open windows using guile-gtk from _within_ gschem.
 > 

This got me thinking about how the history of the code choices used in
gEDA.  The email archives gives a few clues on how the choices have
been made regarding the use of external libraries, but it still isn't
clear to me why some options are not considered.  Is there an
architecture document that helps in understanding the thought process?
I agree that not requireing guile-gtk is a good idea, but are you
adverse to considering other libraries because they would add
dependancies?  For instance, have you looked at Dia
http://www.lysator.liu.se/~alla/dia/ and the dia-newcanvas
http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=dia

Dia is a Visio like drawing tool.  One of Dia's examples is a
schematic drawing tool and another example is a UML drawing tool.  The
core of Dia is a high level drawing framework that standardized set of
features to manage structured graphics  (some of the ideas remind me
of the old idraw tool).  One capability that is immediately useful go
gEDA is the attachment points on objects.  They allow a line
to be attached to an object so that when the object is moved the line
streches to follow.  The dia-newcanvas is abstracting the
management functionality of Dia into a new canvas that adds
capabiliites missing in the gtk canvas.  

I would expect dia-newcanvas to be a good substrate for gEDA.  The
project is under active development by James Henstridge
james@daa.com.au and friends.  James is a real coding dynamo.  He's
done great things with libglade and the python mapping to gtk and
gnome.  

The gEDA project already a significant code base, but perhaps some
code could be shed (and the need to maintain it) if the level of
abstraction were raised some and started building on some of the newer
gtk libraries and tools.  The use of Glade, for instance, would save
much effort in laying out the user interface.  Much of the
link/compile/debug cycle could be avoided by useing libglade to manage
the layout and drawing of the GUI.  Xroadmaker at
http://xroadmaker.sourceforge.net/ was done by two students using
Glade.  The twelve screen shots half way down this page show how much
work can be done with little effort by using Glade.  The use of
libglade could have some them more work.