The main user interface type in use on the UNIX platform today builds on the X Windows set of standards, protocols, and libraries. To gain an understanding of how to migrate such a user interface, it is worth comparing the user interface architecture and the resulting look and feel in the two models. Finally, it is useful to understand differences in windowing terminology between the two environments.
The architecture of X Windows-based interfaces differs significantly from Microsoft Windows architecture. First and most fundamental is the orientation of client and server. For X Windows, the client is the application that requests services and receives information from the user interface. The user- facing elements of the interface are based on what is termed the X Server.
In the X Windows-based system, the client application sends requests to the server to display graphics and to send mouse and keyboard events. The X Server is responsible for doing all the work on the client s behalf . The client might run on a remote system with no graphics hardware or on the same physical computer as the server. In either case, the client does not interact with the display, mouse, or keyboard. This is shown in Figure 11.1, which represents the X Windows client-server architecture.
By contrast, a standard Win32-based application is not responsible for dealing with the display, mouse, or hardware. Figure 11.2 shows the path from an application down through the layers to the hardware in the Microsoft Win32 environment.
X Windows is normally used with the Motif widget library, which is a library of user interface components ” such as scroll bars, buttons , drop-down lists, and dialog boxes ” that can be used off the shelf. Because many X Windows-based applications use Motif s look and feel, Motif has transcended being considered just a third-party library, to the extent that some developers consider X Windows and Motif as one and the same.
According to the Motif Programming Manual and the Microsoft Official Guidelines for User Interface Developers and Designers, all applications that a user can run on the desktop should have a consistent look and feel as well as functional design. Anything else is likely to confuse users, possibly to the point where they will not use the application.
Although there are many differences, Microsoft Windows and X Windows with Motif both have roots in the IBM Common User Access (CUA) guidelines. The resulting similarity in look and feel is not too surprising. Every windowing system needs to perform the same tasks :
Determine which font is used to display text.
Determine background color .
Specify where a check box appears.
Show that a user has clicked a particular button.
After satisfying the task list, it just becomes a matter of methodology. Notice the similarities in terminology and appearance of dialog box elements in Figure 11.3 and Figure 11.4.
Note | To ensure a consistent look and feel with other Windows-based applications, migration of X/Motif applications to native Microsoft Win32 should be governed by the official Microsoft guidelines. |
Windows types are very similar between the X Windows and Windows environments, as detailed here.
The X Windows system automatically creates the desktop window. This is a system-defined window that is the base for all windows displayed by all applications. In X Windows, it can be thought of in the same general terms as the root window.
A Win32-based application can retrieve a handle to this window by using the GetDesktopWindow() function.
The Application Window is the interface between the user and the application. Elements such as a menu bar, window menu, minimize and maximize buttons, close button, title bar, sizing border, client area, and scroll bars typically appear in the Application Window.
A user typically accesses a dialog box as a temporary window used to create some additional input. A dialog box contains one or more controls, such as buttons and check boxes, to elicit user input. A developer can build an entire Win32-based program by using dialog box functionality.
When the system creates a modeless dialog box, it becomes the active window. The modeless dialog box does not disable its parent window nor send messages to its parent window. However, it stays at the top of the z-order even if its parent window becomes the active window.
Applications can create a modeless dialog box by using the CreateDialog() function, with arguments to specify the identifier of a dialog box template and the pointer to the callback procedure that handles messages for the window.
A modal dialog box becomes the active window when the system creates it. Until a call to EndDialog() , the dialog box remains the active window. Neither the application nor the user can make the parent window active. EndDialog() must be called.
An application uses the DialogBox() function with a resource identifier to create a modal dialog box. Use a modal dialog box when it is desirable to force user input before proceeding.
A message box is a special dialog box that displays a note, caution, or warning to the user. For example, a message box can inform the user of a problem the application has encountered while performing a task.
Table 11.1 compares popular subject matter for X/Motif and Microsoft Windows. All of the Microsoft documents are accessible from the MSDN Web site.
X Windows Reference | Microsoft Windows Reference |
---|---|
Motif Style Guide | Official Guidelines for User Interface Developers and Designers |
Motif Programming Manual | Platform SDK: Windows User Interface |
Motif Reference Manual | Platform SDK: Windows API |
To download the Microsoft Platform SDK, go to the Microsoft Web site ( http://www.microsoft.com/ ) and click Downloads. From the list of available downloads, type Platform SDK in the Product Name box, and then follow the instructions to download it.