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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
