Resist the urge to dive right in and start transforming your code to Solaris Motif. Begin the process of porting your application to Motif and CDE by examining your application's architecture.
The more architecture your application has, the more important it is to re-architect the application correctly up front. In these situations the complexity of the porting process increases dramatically if you use the "convert and clean up" strategy.
For programs in which important functions are insulated from the surrounding GUI, the impact of the difference in the OPEN LOOK user interface and Motif can be negligible. However, if the code is tightly linked to the user's actions or relies on a specific OPEN LOOK feature, producing a Solaris Motif equivalent may be difficult.
If you can draw a line through your code modules and completely isolate those that constitute the user interface from those that make up the remainder of your application, then you can focus your migration efforts on the process of replacing the user interface modules with equivalent ones developed for Motif. Many application developers follow software development methods that require this kind of clean separation and, in some cases, even formally specify the program boundaries between user interface and application internals.
Alternatively, if your software is more monolithic and has application-specific abilities embedded within functions that also provide the user interface, then you may have to spend extra time separating the two types of functions, thereby complicating your migration. In an extreme case, you must choose between violating the style guide or redesigning part of the program.
The amount of time involved in taking full advantage of the Solaris CDE software significantly depends on how your application is laid out. Applications that are well designed are easier to port and to properly break down for maintenance and readability.
As mentioned previously, porting your application to Motif is not an object-for-object swap. Such swapping concentrates on the static aspects of your application user interface. Complex applications in particular contain many objects that manage the application infrastructure and make it work in dynamic situations. (Dynamic aspects of your application include, but are not limited to, resizing windows, localization, and font changes.) These manager widgets that handle the dynamic geometry in your application are different in the OPEN LOOK and Motif toolkits. Your application will not display the dynamism you want if you try an object-for-object swap of manager widgets. Introducing an appropriate design to handle the dynamic aspects of your application typically increases the complexity of its architecture.
XView does not provide much variety for dynamic layout. It primarily fixes objects at (x, y) positions, which can cause difficulties if an application font is changed or the application is localized. Motif and OLIT provide a variety of geometry manager widgets; however, they have significant differences.
Table 6-1 OLIT and Motif Geometry Manager Widgets
The CDE desktop is quite different from the OpenWindows desktop, although it contains many of the same types of tools. The most obvious difference is that it is a Motif desktop. Read the "Architectural Overview" chapter of Common Desktop Environment: Programmer's Overview for a discussion of the end user and development environment architectural structure. Also read about:
Motif: See "Motif 2.1 Documentation" and "Motif Programming" for a listing of Motif documentation.
CDE Look and Feel: Refer to Common Desktop Environment: Style Guide and Certification Checklist for details. To be style-guide compliant, your application must pass the checklist at the end of the book.
CDE runtime and Development Environments: See "CDE Documentation" for a listing of all CDE documentation that Sun provides. In addition, the desktop applications each have online help volumes.
If you used a Motif GUI builder to create the GUI for your application, your migration to the Solaris CDE desktop will probably be easier. In most cases, the use of a builder implies that you have some degree of separation between user interface functions and application internals, the advantages of which were previously discussed.
Also, builders typically use generalized internal storage formats or are capable of generating interchange files, each of which may be post-processed to automate some of the conversion process. Contact your builder vendor to see what migration tools they are currently offering.
Other less tangible tools that you might have used and that could ease your transition include development approaches that produced functional requirements documents or high-level designs. These representations may describe your application in terms less specific to the OPEN LOOK user interface that are more amenable to being mapped to CDE and Solaris Motif than your source code.