[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA-dev: Google Summer of Code Mentor Summit
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.
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev