Apart from the DOS/Windows environment, OSF/Motif is the GUI used by the majority of workstation vendors for desktop systems. In particular, Motif is the interface of choice on all major UNIX platforms. With the creation of the COSE initiative, Motif has been adopted by Sun to replace its own Open Look style. Sun is now shipping a Motif development kit and will be shipping the Common Desktop Environment which will provide a complete Motif GUI. For its part, Digital Equipment Corp. uses a Motif interface for OpenVMS as well as for Ultrix and DEC OSF/1. Motif development kits are also available on a wide range of systems, from Intel x86-based PCs running DOS/Windows to mainframes running operating systems such as MVS. With such momentum behind a single interface style, it is likely OSF/Motif will continue to be the user interface for UNIX-based systems, as well as for integrating applications into a corporate environment.
Motif 1.2 is the most commonly available release. It includes support for internationalization and localization of applications and the addition of an API for drag-and-drop. Motif 2.0 is the most recent release, although it is not commonly used. It contains more API changes and represents a nearer convergence with the style guides of PC windowing systems.
In conjunction with the increased use of Motif, there has been a rise in the use of Motif GUI builder tools, which have made the creation of Motif interfaces relatively straightforward. But as the definition of the Motif GUI changes, the tools used to create Motif interfaces have changed to provide developers with access to new features. Still, simply having a tool that can generate code does not mean that good code will be generated. Without knowing the ins-and-outs of their tools, interface developers can create GUI applications which are at best marginally useful and at worst completely unmaintainable.
Geometry Management
One particular area which can give Motif programmers headaches, especially developers moving from Windows to Motif, is ``geometry management'' --- a complex X Window mechanism for components (or widgets) within an interface to negotiate a desirable size for themselves and their container components. Each container in a widget set such as Motif provides a specific set of semantics for how its children will be laid out and for how the container will deal with requests for changes in size and position. Motif provides a powerful geometry manager in the XmForm widget. XmForm can, however, be an extremely frustrating widget with which to work, since the semantics it establishes for geometry management are very complicated. However, you can simplify the process of dealing with the XmForm by following a few simple rules:
*Create the children of the Form in a roughly row or column order. That is, start at either the upper-left or lower-right corner and work outward.
* If you want a widget to resize in the horizontal or vertical direction, attach both of its sides. To keep it from resizing in one or both directions, attach only one side.
* Nest XmForms within XmForms. Doing so will simplify the geometry calculations performed by each form and ensure that the desired layout and resizing characteristics are achieved.
GUI builders that provide some sort of editor for the XmForm attachments make it easier to follow these rules. For example, the Builder Xcessory (from ICS, the company I work for) uses icons to show the XmForm attachments on each side of the currently selected widget, and lines showing where the given side of the widget is attached. Providing some sort of editor for the XmForm layout constraints is usually a feature of mid-range tools or user-interface management systems (UIMS). UIMSs are GUI builders which focus on the management of the entire application from the viewpoint of the GUI. They generally have run-time components which provide complete separation of the interface and the underlying application. UIMSs often provide an API different from the underlying windowing-system toolkit, that provides access to all aspects of application coding. Because of this, UIMSs are often geared toward providing a cross-platform solution for application development. The UIMS API is consistent on each platform for which it is intended to run. (This means if you develop your application using only the API of the UIMS, it only needs to be recompiled on each of the supported platforms in order to be ported.) Interface design tools (IDTs) often only allow the user to modify the constraints through indirect means. Being able to directly manipulate the interface under construction is a great boon to the GUI design process, allowing you to quickly and easily try new configurations for your interface.
X Toolkit Geometry Negotiation
As an example of geometry negotiation, consider a Motif PushButton placed in a RowColumn. By default, the PushButton will try to resize itself to be large enough to display all of its label. In order to do this, it must first ask its parent, the RowColumn, if the new size is acceptable. The RowColumn then calculates if the requested size would require it to change size. For example, the most common method of management used by the RowColumn is to keep all of its children the same height and width. If the PushButton requests a width that is larger than the current widest width, the RowColumn needs to grow in order to accommodate the new size. If the RowColumn needs to grow, it asks its parent for the new size, and so on up the parent-child chain.
At the top of the parent-child chain, the requested size of the entire window is accepted, rejected, or almost accepted. The accepted and rejected cases are simple. The response is passed from parent to child until it returns to the original requestor (the PushButton).
At any point on the way back down the chain, the response could be changed to an ``almost'' response. This response indicates to the child that its request cannot be completely honored, but that an alternative geometry is acceptable. The child may, at this point, accept the alternative or attempt to negotiate another geometry. In most cases, the child will accept the alternative. In the end, the PushButton, which made the original request, will reconfigure itself to its new size.
Conclusion
It is easy to see that the X/Motif environment provides a great deal of power for GUI designers. Unfortunately, effectively using that power to create pleasant, easy-to-use interfaces, which can easily be moved from one platform to another and localized for any number of countries, can be a complex and somewhat daunting task. Luckily, a wide range of tools is available to aid developers in the process of interface construction.
Scott is a senior software engineer for Integrated Computer Solutions and can be contacted at [email protected].
