However, GUI design is very geared towards surface values. The last week has been a not-so-dear reminder of the age-old adage that the GUI takes at least twice the time of the rest of the applications - regardless of its complexity.
I started out using Walter Zorns DHTML library, which works well even if it's a little low-level. I really wanted to constrain element placement to specific areas of the screen (The main canvas, for instance), and so I experimented with using dojo's DnD, which turned out to be much easier - at least to begin with.
Unfortunately, one major drawback with the current implementation of drag-n-drop in dojo 4.2 is that dragging also triggers moving, so you end up hauling your resizing element halfway across screen, when it should have stayed put.
Also, I have completely failed to understand how to use hierarchical and multiple drop targets simultaneously, so that you can nest elements, drag nested elements out on to the canvas again, or onto another element, properly.
So at the moment, I'm trying to shoehorn my ambition inside open jacobs draw2d library, which is built on top of WZDHTML, but with a lot of added functionality, especially the nice "green corner resizing blobs" and selection logic, as well as fairly simple drag and droppability, events, cross-browser brains, et.c.
But.... there is no explicit logic in draw2d for handling nested figures. So when doing the "obvious", i.e. adding one "Figure" objects html element as a child of one other, the highlighting, resizing blobs and stuff gets misplaced, but follows the movements symmetrically. Not good.
I'll probably hack around in draw2d to see if I can understand why it doesn't work, but if all else fails, I'll ironically move back to plain vanilla walter again, just to get things moving.