Crunch CRiSP File Editor 6 - Manual (Page 54)

Page 54
creating a dialog box.
1. Firstly, we sketch or conjure up a mental model of what the dialog box is going to look like. E.g. we
consider the user interface components, such as input fields, toggles, push buttons. Most dialog boxes
have a common core of functionality, such as an OK and CANCEL button. Stylistics issues dictate that
these are normally at the bottom or right hand side of a dialog box.
2. Next we look at each user interface object and decide what its purpose is, how it responds to user input.
3. We then sketch up a prototype showing visually what the final dialog box will look like, without any
semantic code to implement any actions.
4. Next we write the code for each object within the dialog box in turn.
5. We can then look at the dialog box as a whole and test it so that there are no unnecessary interactions
between the individual components. (E.g. we may decide that the <Enter> key is used to insert a line of
text in our input field, but this may conflict with <Enter> being used as the default action for the OK push
button).
6. Finally we integrate the dialog box with the rest of CRiSP, maybe adding a new menu option or icon to
invoke the dialog box.
What started out as a simple idea can lead to a lot of coding and trial and error until the dialog box finally
performs as we like. Sometimes, we may find limitations. For example, some semantic action may not be
achievable and the overhead of coding for certain actions may be so large compared to the rest of the
coding that it may be a matter of accepting what is achievable rather than striving for perfection. This is a
common way of coding and is responsible for glitches in the workings of many user interfaces.
Now lets consider these steps again. The first part of sketching a user interface may seem trivial but the
more effort put in at this stage then the easier it will be to come up with the final result and avoid huge
amounts of debugging.
The next stage is to try and come up with a user interface prototype of the dialog box. This is a fairly
mechanical process with a certain amount of trial and error. It can be very daunting trying to understand why
there are so many objects and attributes and which can be used together. Until you understand the rationale
for these attributes you will be programming in the dark, and will end up resorting to trial and error. This is a
fact of life for many newcomers to windowing systems programming. It is simply not possible to absorb the
thousands of pages of documentation which accompany commercial window systems, and it can take many
months or years to reach any level of competence.
Coding of the semantics for each user interface component is fairly straightforward but this is where all the
errors in the user interface will creep in. We simply try out each object in turn, clicking, dragging, selecting,
etc and putting in the code to handle each event.
The later parts of the testing will involve refinement of the coding stage as conflicts and changes in ideas
surface.
Overview of an Object
A CRiSP object is equal in status to a Windows child-control or an X11 widget. It is a name to refer to a type
of user interface object, which responds to some user input and can issue callbacks. An object is an entire
subsystem in itself. If you look at CRiSP buffers, or windows, you find that there are ways to create the
objects, and various functions for retrieving and setting attributes. Objects are similar in this respect, but
instead of having hundreds of primitives which control the way an object works, we refer to attribute values.
An object is a reasonable term to use, since the user is not concerned about the implementation of the
object, and a certain amount of class inheritance is used internally to provide a more consistent way of
handling and looking at the objects. Each object has numerous attributes which control its behaviour; some
of these are specific to the actual type of the object, e.g. the bitmap used in an icon, whereas other attributes
are generic to all the objects, e.g. the (x,y) co-ordinates of the object.
Objects can be considered to be implemented from two parts: a part called the core part (similar terminology
to the Xt library), and an object specific handler. By thinking of objects in this way, it is a lot easier to
understand where to look for specific documentation on the attributes available for each object. In terms of
the actual implementation, this means a lot of common code is shared amongst the objects, and in terms of
the documentation, it means there is no need to repeatedly document the common attributes to all the object
types.
At the most basic level, you can think of a dialog box as an umbrella containing a collection of objects inside