Z**D

Well I've been hacking on, of all things, a 2D structured diagram drawing application.

It came out of a lack of satisfaction with pretty well any GUI application I've tried. They look good on paper but when you try to do things with them you find all sorts of nasty limitations. One of the biggest problems they have is creating lots of objects of the same kind with different settings (think, uml classes). On the other hand, there are purely text or language based formats, which are good for editing lots of items quickly, and you can control layout very well, but they have steep learning curves, and making small tweaks to attain visual perfection is very time consuming. I haven't had the chance to use many CLI applications -- perhaps GNUPlot is the closest. They provide graphical output but no chance for graphical input. Like GNUPlot, many are focused on scientific users too.

So I want to experiment with a combined CLI, GUI, and ``active source'' user interface. I guess it might end up being a bit ambitious, but it'll give me something to keep me off the streets for a while.

(not the real intended structure, but a quick diagram I whipped up to test some code)

Some of the ideas so far:

• CLI, GUI, and programming language are all fully first-class interactive data input options.
  
• CLI is an old-school CAD-like interface, where data can be input numerically.
  
• A ``live'' text editor where edits are reflected in the display at or near real-time.
• A typical pick'n'place GUI as well, at least for creating objects and adjusting layout.
  
• Item references in CLI or Editor or GUI are highlighted in the alternative input views.
• Declarative language allows flexibility, yet still allows direct GUI relationships.
• Language more human oriented than parser oriented.
  
• Custom graphical objects defined in declarative language, including object-like features.
• Custom graphical objects also defined in Java classes.
  
• Flexible layout mechanisms based on anchor points and vector arithmetic. Somehow available from GUI too.
• Heirarchical objects and grouping.
  
• Cascading styles using same syntax as language.
  

I'm more interested in the HCI factors than producing a real product, but I guess I'll see how it goes. And how long I keep interested.

I've done some work on the language parser, and the language itself is an interesting problem, and there's plenty of room to experiment. Do I go for minimalistic syntax, and put more of the semantics into the execution of the AST, or do I wrap up more of the language in reserved words? Do I use special symbols (e.g. ~ for a curve, "foo" for a label), or stick to English keywords (curve x ..., label "blah" ...)? GUI-modifications-to-source operations --- essentially graphical refactoring tools --- will probably be quite some work too.

And I have some layout code that mostly works. Although I've already hit some issues with containers which must automatically size to their contents. Because of the arithmetic and relationship based layout system there is the potential for complex relationships that are difficult, expensive, or impossible to calculate using recursive layout procedures and delayed arithmetic. Maybe linear programming will come to the rescue, if I can get my head around it - should be able to just calculate all the layout at once. But ... It will need some symbolic expression refactoring, which doesn't sound too fun.