Timothy Normand Miller wrote: > > What does _your_ perfect IDE look like? (For all values of "you" on this > list.) > > Ok. This is incomplete and not fully thought-through (I had planned > on figuring out what worked and didn't as I went along). > > > At any point in time, you are looking at a module and its immediate > submodules. Optionally, you can view even more levels, but that is > something that you wouldn't want to have enabled all of the time. The > current level module is represented as a rectangle that can be zoomed > or fixed to the size of the window, decorated on the outside with its > I/O ports. Those ports can be dragged around, added (drag in from a > palette?), removed (dragged off into space?), renamed (dclick?), and > have other attributes (bus width, etc.) edited (right-click?), have > their name changed, etc. > > Inside of the current module, you can drag in from a palette various > template modules. Generic containers that just let you write your own > Verilog code or more complex things like pipeline stages. These can > be dragged around arbitrarily inside of the current module. They can > have ports added, removed, dragged around, renamed, edited, named, > same as the top level. Some way must be provided to connect (wire) > ports of submodules (shift + click, drag?) to each other and to the > ports of the surrounding module. Select a wire and press delete to > move it. Lasso a bunch of them to move, connect, disconnect in > relative unison. Use some kind of snapping thing to automatically > connect to nearby ports. > > Double-click (maybe) the empty space in a submodule to expand it. It > now becomes the current module, and you see its submodules. Some "up" > toolbar button would go up a level.
The most surprising part of the description so far was, how unsurprising it was. This all seems to be the most natural way to have a hierarchical GUI for schematic design. This fact inspired me to dust off my prototype and get it to compile. Currently, it contains little logic and consists mostly of Gtk and Cairo calls, so that it can be easily ported to other languages and serve as a starting point for the Summer of Code project. The only working functionality so far is the zooming with the mouse scroll wheel. The source and a precompiled binary are available at http://v2os.v2.nl/~vp/hide.tgz The program is started from the main directory as "bin/hide". To test multithreaded rendering (can one even *buy* single-core desktops nowadays?) it can be started as "bin/hide +RTS -Nx", where x is the number of cores/CPUs. Since I didn't yet figure out how to build Debian packages for Haskell programs, the binary may need some additional libraries. I don't have a fresh system to test which libraries are needed, but judging from the output of ldd, the packages libc6-i686, libglade2-0, libgmp3c2 and their dependencies in the current Debian Unstable should provide everything necessary. Compiling from source requires GHC and the Gtk2Hs developement libraries. I'm using the EclipseFP Haskell plugin for eclipse, so the project files for that are included, too. The compile command for those who don't want to bother with Eclipse is included in the script called "make". > I think "save" should go the way of the dodo. One of those UI design > tutorials linked to through OSnews (check them out!) described this > financial app. When you want to add a transaction, you click some + > button and fill out a form. When you're done, you just do something > else. If you want to edit it, you select the entry and start editing. > iCal on the Mac is like this. We should think this way! No more > lost work due to crash. No more forgetting to save. But say you want > to revert to an earlier version? Simple: Excellent Undo capability > and revision control. We need to decide if that's an innovation we > really want to make for this, because we'll have someone wanting to > hit Save and immediately switch over to ISE and his Synthesize. If > we're saving on some timer, they could get ahead of us by half a > second and have inconsistent files. The synchronization problem can be solved by integrating launchers for external tools into the IDE. The undo functionality itself, in purely functional languages like Haskell, is available for free: data structures are modified by creating a new structure and reusing unmodified parts of the old one. Therefore, storing multiple versions scales proportionally to the amount of change, not to the size of the entire structure multiplied by the number of versions. In other languages, this will have to be implemented explicitly, but the general principle can be copied from the functional paradigm. One big design question remains: the file format. Storing the schematic as just Verilog will not work, unless we implement a P&R algorithm which can deterministically layout any loaded Verilog module so well, that a user won't even *want* to move stuff around. The 2D layout will need to be stored either in Verilog comments (ugly) or in a separate file (incosistencies). I would prefer the former option and trying to improve the P&R to minimize the amount of information which needs to be stored in comments. A realistic goal would be to merely need the positions of ports and maybe an orientation of some submodules relative to each other (e. g. "A is east of B"). - Viktor Pracht -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
