Chapter 1

� if the Set interval button is selected, the Set time button should be deselected, and the
remainder of the dialog should change appropriately (in this case, the time editors are
replaced by a choice list for selecting time intervals);
� if the user sets two Check for new messages at values to be the same, as in Figure
12.3, then the second value should be dimmed when the user moves away from the line
on the dialog or presses Done. It makes no sense to schedule two downloads to take
place at the same time.
12.2.2 Some Basic Abstractions
On the basis of this list of user requirements, you can see some abstractions beginning to
take shape:
� The highlight (or in text editors, the cursor) is actually a visual indication of focus. The
control that currently has focus receives the majority of key events; it therefore ought to
know whether it has focus or not, and draw any necessary highlight accordingly. (Not all
key events go to the control with focus: in dialogs, pressing the hardware Confirm key
causes the default button – usually Done – to be pressed, rather than going to the
highlighted control.)
� A control needs to be able to refuse interactions such as pointer events. Invisible or
dimmed controls should certainly refuse interactions. A control should know whether it
is dimmed and thereby draw itself in a suitable way.
� A control needs to be able to say whether it is in a valid state, and to respond to
queries about its state.
� If a control's state changes, it needs to be able to report that to an observer such as
the dialog, so that the dialog can handle any knock-on effects. (For example, if the
checkbox changes to indicate no scheduled downloads, the dialog must make it
impossible to select the other controls.)
These are the user requirements. Throughout the rest of this chapter, I'll be describing how
the GUI framework makes it possible for you meet them.
12.2.3 Programmer Requirements
If ease of use matters to end users, it certainly matters to programmers, who will have some
requirements on the way all the ideas raised above should hang together:
� It should be possible to invent new dialogs with rich functionality and to implement the
validation rules with sufficient ease that programmers will want to use these facilities to
deliver helpful and usable dialogs.
� It should be possible to use any control in such dialogs – not only the stock controls
provided by Uikon and UIQ but also any new control that you invent and wish to include
in a dialog. (Not all controls are designed to be included in dialogs. I don't see any need
to include my fleet view in a dialog.)
� Given the number of different ideas here, it should be possible to write code that
supports only the things you require for a particular control, without having to worry
about implementing things that are unnecessary. Furthermore, you need to be confident
that you've decided to include only those things that need including and to exclude only
those things that need excluding.
12.2.4 Compound Controls
I began to introduce the idea of compound controls in relation to drawing. It turns out that
compounding also makes it very much easier to implement general-purpose containers such
as dialogs. Returning once again to our e-mail account dialog, the visible controls on it, from
the top, are as follows: