next up previous
Next: Implementation: how it works Up: The ``Dashboard" application: a Previous: The ``Dashboard" application: a

Functional requirements

Another challenge facing us was our need for a good GUI (or several) for this very complex instrument. We require an engineering interface for bench tests, development, pre-ship qualifications, etc.; and we require a finished, friendly, highly documented GUI for the end-user (astronomer) who will use the instrument at Keck-II. In the past we have hand-crafted GUIs using C and the Xt toolkit, and some personnel at CARA have used the commercial DataViews [DV] product extensively to design custom interface panels for instruments or instrument subsystems.

Our approach to the generation of documentation, code, etc., convinced us of the significant benefits of maintaining one authoritative source of keyword (i.e., design and specification) information to be used by many applications. It was my personal conviction that the UI should not be a specific, handcrafted product tailored for DEIMOS, but a generic ``soft" application capable of reading the keyword database and configuring its behaviour accordingly.

The GUI should provide the user with a body of knowledge about keywords and their legitimate use, and with a ``toolbox" of graphical and text widgets which could be associated with these keywords. The end result would be a control GUI for any KTL control system (really, for any keyword/value control system). It should not rely on any commercial or license-restricted software; although we started this project using the Sybase RDBMS, one could use the free PostgreSQL RDBMS [PgSQL] with the pgtcl extension). It should be portable to any Unix platform (including Linux on laptops).

In sum, the finished product should be a dashboard builder, not just a dashboard. The UI that ships with DEIMOS should be merely one frozen layout created by an inherently dynamic tool. If we could apply the same tool to any KTL system, then the UI for ESI and for DEIMOS would share development costs, and it should be cheap and easy to design supplemental or improved GUI for instruments already deployed. It should be absolutely trivial to change the surface appearance of the GUI at any time, in response to user requests or operational/procedural changes.


next up previous
Next: Implementation: how it works Up: The ``Dashboard" application: a Previous: The ``Dashboard" application: a

De Clarke
Wed Jul 23 15:09:14 PDT 1997