There is a fair amount of waffle in this email, but hopefully it has some ideas for the (perhaps long term) future. I think if we could implement it, then it would _definitely_ get used in teaching - at least here.
On Thu, 2007-02-22 at 19:27 -0500, al davis wrote: [snip] > Gschem needs three things to make this happen. > > 1. The ability to have a user defined menu, that can pass > messages to another program. I'm sure this could be implemented. > 2. The ability for an external program change attributes by > sending a message, and for these changes to show immediately if > that attribute is visible. A little D-Bus interface to the API here would go a long way. I'll use the term IPC from now on, recognising that D-Bus isn't the only way. If you think of it more as a generic multiple view interface, this is actually the same functionality which needs to be supported by libgeda to allow multiple programs - gattrib, gschem, PCB? to work on the same open schematic. A means to wake and callback into the program which cares about a change is a must. This is on our wish-list. It could be that the first program to load a schematic gets control of it, and other apps talk to the first via IPC. It could be that opening a schematic instantiates a "server" app which takes control of the schematic, and all UI apps working on that schematic talk to it via IPC. libgeda would make this transparent. I guess it would be possible to write a gnucap plugin which talks to a running gschem / libgeda via some IPC (such as D-Bus), allowing gnucap to "work" on the same open schematic. It would be a netlist reading plugin. Then there is just some means of "remote controling" gnucap and getting its output. For D-Bus, this would all require gnucap's core API to have a main-loop with support to wake using poll or select, and to expose means to add hooks into this main loop. I guess any "user-interface" plugin requires some means to get the OS to wake and accept commands - ideally not just by blocking from within the plugin code. The requirement is new for netlist reading plugins, as I presume they don't expect changes on the fly. More simply, you could write code in gschem which launches and talks to gnucap using normal file descriptors. If you are hiding gnucap's UI, you may as well close and re-invoke it every time you want a simulation. For teaching use, it would be nice if you can just change a resistor value in the schematic, and have the change automatically propogate into gnucap, re-run the simulation, and update plots. For simple circuits this ought to be quite fast. It might require that a simulation can be interrupted during a run and re-started, if multiple changes are made before the simulation finishes. > 3. The netlister must work, 100%. You should not need to > explicitly run it separately. How about an "export" in the > file menu, like word processors make pdf? This was on the CUED wishlist too. If gschem understands connectivity, there is ability to do back probing, and more on-the-fly cooperation between PCB and gschem - should the designer so desire. Links to multiple schematic pages might require some thought. > But this is for a look-alike transition. Having the simulator > commands/menu separate from the schematic is not a problem. I'll confess to only having watched others use PSpice, OrCad etc.. I didn't think PSpice's schematic _looked_ too bad, but I've never found a tool as easy to use as gschem. For really grabbing users, what we need is waveform viewing with the likes of PSpice, or Matlab's graphing capabilities. (Octave suffers similarly from poor graphing support). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
