If you want to port an OPEN LOOK or Motif application to the Solaris CDE desktop, you need to consider the development environment transition as well as the graphical user interface (GUI) transition. The OpenWindows and Solaris CDE development environments are different in many ways but similar in others. This chapter compares and contrasts the two development environments.
The Solaris CDE desktop is based on the same X server as is part of the OpenWindows environment. For example, you can access Display PostScriptTM (DPS), and the XILTM and XGLTM libraries from Solaris CDE.
This section briefly describes the features of the Solaris CDE development environment that do not appear in the OpenWindows environment in any analogous form.
Desktop Korn shell: Provides a way to engage in graphic user interaction through shell scripts. See Common Desktop Environment: Desktop KornShell User's Guide for detailed information on desktop Kornshell.
Workspace Manager: Provides support for multiple workspaces. Each workspace is a virtual screen. Most desktop applications can run as expected without knowledge of the Workspace Manager. See Common Desktop Environment: Programmer's Overview and Solaris Common Desktop Environment: Programmer's Guide for more information on the Workspace Manager.
This section contrasts some of the functionality that OpenWindows and Solaris CDE development environments have in common, but that might be implemented differently.
Both the OpenWindows and Solaris CDE development environments contain GUI application builders.
The OpenWindows Developer's Guide (Devguide) is a tool that helps produce the GUI for OPEN LOOK applications. Devguide has code generators that produced XView and OLIT source code. The Devguide Motif Conversion Utilities product, which was first shipped with the Solaris 2.3 release, produces Motif code from Devguide GIL files.
CDE Application Builder (App Builder) produces Solaris Motif code. It also enables you to integrate some of the desktop services into your application; for example, drag and drop, ToolTalk messaging, sessioning, help, and internationalization. If you used Devguide to create your application, you can use App Builder's GIL-to-BIL converter to create BIL files, which is the format the App Builder uses.
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.
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:
It is easier to use than the APIs that Motif 1.2.3 provides
It defines and implements data transfer policies
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.
OpenWindows ToolTalk messaging is compatible with the CDE ToolTalk Messaging Service. In addition to the OpenWindows ToolTalk functionality, the CDE ToolTalk Messaging Service provides:
The tttrace utility is a debugging tool that helps monitor ToolTalk API calls and ToolTalk's internal message processing.
The ttsnoop utility is a debugging tool that helps monitor messages that are sent between your application and other applications.
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.
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:
A database that stores file type names and attributes
A collection of routines that query the database
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.
CDE help differs from OpenWindows help in three areas:
User model
Programming tasks
Richness of help system
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.
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.
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:
Establish help callbacks on all relevant widgets.
These callbacks must be able to provide the help information for the associated widgets.
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.
Implement on item help.
Common Desktop Environment: Help System Author's and Programmer's Guide provides source code to do this.
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.
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.
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.
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.