Solaris Common Desktop Environment: Motif Transition Guide

OpenWindows Versus Solaris CDE Development Environments

This section contrasts some of the functionality that OpenWindows and Solaris CDE development environments have in common, but that might be implemented differently.

GUI Application Builders

Both the OpenWindows and Solaris CDE development environments contain GUI application builders.

If you have used Devguide to build an application, the CDE Application Builder will feel very familiar to you. The palette is visually similar. Much of the Devguide functionality is retained, such as the Build and Test feature and the ability to build projects.

See Common Desktop Environment: Programmer's Overview and Common Desktop Environment: Application Builder User's Guide for more information on App Builder.

Drag and Drop

The underlying basic functionality of OpenWindows drag and drop and CDE drag and drop are similar. Both versions of drag and drop contain general purpose APIs that provide the same outcome from a user's perspective.

However, CDE drag and drop also provides a convenience API that serves two purposes:

The OpenWindows environment has conventions for drag and drop policies, but it is up to the developer to implement the policies. If you use drag and drop in your OPEN LOOK application, much of the data transfer code you wrote can be condensed by using the CDE convenience APIs.

See Common Desktop Environment: Programmer's Overview and Solaris Common Desktop Environment: Programmer's Guide for more information on CDE drag and drop.

ToolTalk Messaging

OpenWindows ToolTalk messaging is compatible with the CDE ToolTalk Messaging Service. In addition to the OpenWindows ToolTalk functionality, the CDE ToolTalk Messaging Service provides:

See Common Desktop Environment: Programmer's Overview, Common Desktop Environment: ToolTalk Messaging Overview, and the tttrace(1) and ttsnoop(1) man pages for more information on the CDE extensions of ToolTalk.

Typing

The OpenWindows classing engine identifies the characteristics, or attributes, of files. The classing engine specifies attributes such as print method, icons, and open commands for specific file types. The classing engine consists of two parts:

The Solaris CDE data typing and actions form the analog of the classing engine. The data-typing mechanism consists of two tables (DATA_ATTRIBUTES and DATA_CRITERIA) that specify attributes such as icons, actions, and commands for specific file types. DATA_CRITERIA corresponds to the classing engine's File name space. DATA_ATTRIBUTES corresponds to the classing engine's Type name space. The actions field in the DATA_ATTRIBUTES table corresponds to the former print and open methods in the classing engine. In the Solaris CDE development environment, it acts as a reference to another table called ACTION, and is greatly enhanced over the former classing engine methods.

See Common Desktop Environment: Programmer's Overview and Solaris Common Desktop Environment: Programmer's Guide for more information on data typing and actions.

Help

CDE help differs from OpenWindows help in three areas:

See Common Desktop Environment: Programmer's Overview and Common Desktop Environment: Help System Author's and Programmer's Guide for more information on the CDE help system.

User Model

The OpenWindows user model is very simple. The user places the pointer over the portion of the application he wants help on, and presses the Help key.

The CDE user model is similar but slightly different. The user receives help from that portion of the application that has input focus. That is, the user must select a portion of the application and then press the Help key to receive help on that portion.

CDE help provides on item help for those objects that cannot get input focus. You must provide an On Item selection in your application's Help menu so users can access help for those items.

Programming Tasks

Writing OLIT and XView help is very similar. In either case, your application provides the text appropriate for a widget or object, respectively. The OpenWindows window manager determines which application is responsible when the user presses the Help key, and dispatches an event to that application.

OLIT has a specialized Help widget, and XView has a Help frame, that puts the right information into the Help dialog display area and makes the dialog appear on the screen. You either have to include a function call to OLRegisterHelp() in OLIT, or set an object attribute in XView, to enable help on a widget (object).

To provide CDE help with your application, you must:

  1. Establish help callbacks on all relevant widgets.

    These callbacks must be able to provide the help information for the associated widgets.

  2. Create and manage the help dialogs.

    CDE provides DtHelpDialog and DtHelpQuickDialog widgets to create help dialog boxes and quick help dialogs. CDE has one shared help dialog that displays help.

  3. Implement on item help.

    Common Desktop Environment: Help System Author's and Programmer's Guide provides source code to do this.

Richness of Help System

OpenWindows help has a single help dialog in which you can place text only. CDE help is much richer. CDE provides both quick and full help. You can also include much more than just text in your help dialogs; for example, color graphics and hyperlinks. The user can print help and also use navigation facilities to stack and traverse help attached to different widgets.

Internationalization

You can internationalize an OpenWindows, as well as a CDE, application. The steps to internationalize an OpenWindows application that are different in CDE than in the OpenWindows environment are documented in Appendix B, Internationalization and CDE .

See Common Desktop Environment: Programmer's Overview and Common Desktop Environment: Internationalization Programmer's Guide for more information on internationalizing a CDE application.

Fonts

In the OpenWindows environment, the default font type is Lucida. The same is true for the CDE desktop, so the CDE user will see no font style differences from the OpenWindows desktop.

Fonts in the OpenWindows environment have proprietary font names, whereas CDE is open. All CDE font names start with -dt- and are common across all CDE platforms. Both CDE and OpenWindows fonts follow the X11 XLFD font specifications.

In both the OpenWindows and CDE environments, your application should not override the system font defaults. This enables the user to customize his desktop. In the OpenWindows environment, the user can choose font type and style through the Workspace Properties desktop application. In CDE, the user can choose font size through the Style Manager.

In the OpenWindows environment, you have to specify fonts for any locale in which you want your application to run. By using the CDE Interface fonts, your application will run the same across all locales and desktops. If you use Application fonts, you must still specify fonts for Asian locales.

The CDE font aliases are in /usr/dt/config/xfonts/<locale>, where <locale> is the directory corresponding to the locale in which you are interested. The default font resources that the Style Manager uses are in /usr/dt/config/<locale>/sys.fonts.

See Common Desktop Environment: Programmer's Overview and Solaris Common Desktop Environment: Programmer's Guide for more information on CDE fonts.

Motif Applications and Color

The CDE environment changes the color threshold values for Motif; hence, Motif applications may have different colors under Solaris CDE from those in the OpenWindows environment.