GUI Architecture
A basic principle with Uncle Unc is that the user interface layer be as thin as possible, and generate itself automatically from the underlying tree of items. A user interface can be thought of as a set of clothing worn by the Item tree. The item tree should be free to change from one set of clothing to another without losing or gaining any significant functionality (in terms of what properties and methods of the object tree can be manipulated, that is - some interfaces will of course be easier to use than others in particular cases).
The user interface layer should not validate input of itself, beyond basic type-checking, where the type information is obtained from the Item tree.
The user interface should not remodel or re-group the Item tree except where acting on the basis of invisible 'hint' properties obtained from the Item tree.
This is good practice of the 'separation of concerns' principle, and ensures that Uncle Unc client functionality doesn't diverge, and that Item trees remain useable across all client UIs. Further, stipulating an exact fit between Item tree and UI ensures that functionality doesn't get lost between the layers (a problem that may multiply as interface layers are layered e.g. when exporting an Item tree as XML to a remote client that then presents it to an end-user through a second interface.
With this in mind, the codebase used to develop the Sirius GUI was separated at the outset into two packages:
ulu.view.ui contains generic user-centric components that are reusable across any UI, including
- a Navigator object for managing the traversal of the Item tree
- Resolver objects able to translate between objects in the Item tree and text representations of those objects
- Pager implementations for simple containers, containers deriving their children from Iterators and Enumerations, and for containers deriving their children by parsing an Input Stream
- generic manager of grouped widgets in a container
- user manager object able to handle single- or multiple-user models
- the Scrapbook utility View
- thread management utilities and associated custom event-handlers. Because we can potentially invoke any piece of code via an Uncle Unc method, we have to define a UI-independent model for managing asynchronous method-calls in progress. A specialist TaskView for recording such calls is supported by Action and Item listeners that automatically spawn separate threads and add these to the TaskView.
- concept of a bound control (i.e. bound to an Item's property or method) and a factory-based method for matching these to properties
ulu.view.ui.sirius contains the set of GUI widgets built on top of the dog.gui lightweight toolkit. Rather than develop any complex logic code of their own, they draw on the patterns of the generic ulu.view.ui classes.
- A generic ClientPane is defined which exploits the designs of the generic group manager to synchronise all widgets focused on the same View. The UncContainer is a base panel-like widget that automatically groups all components placed into it.
- Most of the 'useful' widgets inherit from this base class.
- dog-specific bound control widgets are provided here, adhering to the generic bound control interfaces and are managed using the ulu.view.ui factory pattern.
This separation should make it easy to develop a swing user interface toolkit should a need for one arise. More importantly, more radically different UIs, such as web-based, voice-based, command-line, and scripting language, have a rich set of well-tested components on which to build.
