Since the dashboard code is basically object-oriented, one might ask why
I didn't use extended [incr Tcl] instead of plain TclX to implement it.
An object-oriented Tcl would have been a more natural choice; I implemented
some OO-like features the hard way. When itcl becomes a standard extension
requiring no core modifications, I'll probably convert ``Dashboard" to
itcl, and the code will then become smaller and cleaner.
The code currently saves its layout to an ASCII file (Tcl source). I would
prefer that it saved this information to a database schema, like its ancestor
the ``fosql" package. However, development was so rapid during the first six
months that I decided to skip the overhead of schema revision and work from
flat files. Storing the layouts in database tables would offer far more
power and ease of access for global modifications, queries about the
tool design, hunting down particular widgets and bindings, etc. I am used
to this convenience in the ``fosql" package and am already feeling
the lack of it.
There is currently no provision for communication between multiple
running copies
of the dashboard. This seems a serious shortcoming, one which must
be remedied before ship date. Since partnered observing is very common
(remote observer on the mainland or in Waimea, in close communication with observers
on the summit), the ability to share dashboard configurations and information
seems essential. This raises all the usual issues of distributed
applications (registry, trust, etc) and rather than reinventing all those
wheels I'll probably evaluate existing Tcl distributed applictions and
copy or adapt a successful design (with the author's permission).
The code does not yet use KTL features like ``callback on move complete"
which would permit us visual indication of moves in progress, and also
to detect and visually flag any drift in stage positions. We are still
struggling (on the KTL side) with issues like ``estimated time to completion,"
``stage position tolerance," and so forth. However, once we have decided
how to encode these concepts in the schema, or how to implement them as
keywords with readable values, it will be trivial to ``teach" the dashboard
how to use them to construct conditional behaviours.