The environment should be object-oriented. The object-oriented [incr Tcl] package was an immense help in developing this editor: it allowed the easy addition and removal of attributes during the development process, and it made most code much cleaner.
The environment must support relationships between objects. In the current editor, all relationships are maintained explicitly by objects' constructors and destructors. Adding a new relationship requires modifying both classes, and this is error-prone.
The environment must support implicit constraints. All constraints in this editor were coded explicitly, and when new constraints are added, many pieces of code must be changed.
The environment must support finely-grained constraints. This editor uses a coarse constraint mechanism: when any part of a master changes, the slave is instructed to recompute everything. This is wasteful: the complex state shape calculation is expensive, and needless when only a state's name changes. Earlier in the development, there were many more expensive calculations and the editor's speed was unacceptable. Even after removing most of these, it is still slower than I would like.
The environment should have support for undo, a cut-and-paste facility, a grid mode, a ``changes have been made'' flag, or a good scheme for keyboard bindings across multiple windows (shortcuts, etc.). This editor does not have these.
To make adding view types easy and safe, the database should have its structural information better-separated from view-specific information. At the moment, structural information and view-specific information are stored in the same class. These should be separated so another view can be added without having to modify (and potentially break) the existing views.
I consider this editor to be a partial success. It does many of the difficult things I intended: multiple views, direct manipulation, and rich graphical objects. But I'm disappointed that the system is so slow---I attribute this to using the [incr Tcl] package and object-oriented features that make the program easier to write, but slower. In many cases, its speed makes it frustrating to use. The solution to this, I believe, is a more finely-tuned architecture, and things like ``pacers'' that keep responsiveness high at the expense of image degradation.
Written by Stephen Edwards.