gEDA-dev: Google Summer of Code Mentor Summit

[al davis]

On Thursday 18 October 2007, Peter Clifton wrote:
> A different end of the spectrum... circuit simulation for
> children. http://gcompris.net/en-electric

... based on gnucap.

> Worryingly, I can see the similarities to some serious
> commercial packages ;)

It depends on what you call serious.  It's not true of the big 
ones from the big 3, but some of the PC based packages are 
surprisingly similar.

> Some GUI integration is a good thing, it reduces the learning
> curve, but for higher education, there is no excuse to hide
> the netlists and engine away. Make tools to navigate them
> from the schematic, or make day-to-day tasks easier.

Sometimes a GUI to generate makes sense, but only if it 
interacts well with manual editing of the underlying file, and 
doesn't obfuscate the underlying file.

> An Autocad like command entry might be good here... GUI
> commands are mirrored in a text command entry which lets you
> know what the real underlying action to the engine is. At
> many points you have the option to click a point, or type
> coords / options etc..

That style was common 15 years ago.  I think it still is on the 
high end.  The low end has lost it. it's all GUI, with the code 
all mixed up, inseparable.

I have always believed that even applications that are obviously 
graphic should be desinged in a client-server style internally.  
A text based engine does the work, text in text out.  Another 
program provides the graphic interface, in such a way that you 
could make it look all graphic if you want to, and still do 
everything in text.  Write the text based engine in a compiled 
language like C++.  Write the graphic part in an interpreted 
language that has good graphic support.

Gnucap does it this way.  Layout and schematic can do it this 
way too.