Architectural Impact

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.

GUI and Internals

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.

Static Versus Dynamic Layout

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

OLIT	Motif	Comments
BulletinBoard	XmBulletinBoard	Basically equivalent; provide static x,y pixel-based positioning for children
Caption	(none)	OLIT Caption widget provides a way to automatically place a label on one of the four sides of a control widget. To get this functionality in Motif, create a separate XmRowColumn widget that contains two children: the label and the control
ControlArea	XmRowColumn	Both widgets provide a way to lay out children in rows and columns.  The OLIT ControlArea widget supports aligning Caption widget children vertically by colon, which the Motif XmRowColumn widget does not. [CDE App Builder provides a geometry manager abstraction called a group that enables widgets to be automatically positioned in common layouts, including being vertically aligned by colon. App Builder generates all the code to implement this functionality.] The Motif XmRowColumn widget enforces certain size policies on children (usually forces children in a particular row or column to be the same size), but the OLIT ControlArea widget does not.
FooterPanel	(none)	OLIT FooterPanel widget provides a way to lay out a window with a floating footer child at the bottom. The Motif XmMainWindow widget can be configured for this layout by setting the "message area child" to be a widget that can be used as a footer (such as an XmForm or XmRowColumn widget).
Form	XmForm	Both widgets provide a means for attaching their children relative to each other and relative to the Form itself, however each takes a different view of these "attachments." The OLIT Form widget provides attachment resources for the x and y dimensions, while the Motif XmForm widget provides separate attachments for all four sides (top, bottom, left, right). You can convert OLIT Form widget attachments to equivalent XmForm widget attachments if both attachment paradigms are well understood. The Motif XmForm widget also provides a special type of attachment called "Position." Children can be attached to dynamic positions in the Form widget which change as the Form widget's size changes. This enables children to be configured to always occupy a certain percentage of the Form widget's real estate.
RubberTile	(none)	OLIT RubberTile widget enables children to be configured to take up a percentage of the RubberTile widget's height (if vertically oriented) or width (if horizontally oriented). In Motif you can achieve similar functionality by using the Position-based attachment resources in the XmForm widget.
ScrolledWindow	XmScrolledWindow	Both widgets provide a way to encompass a child widget into a scrollable view port.
(none)	XmMainWindow	Motif XmMainWindow widget provides a manager that lays out its children into specific areas of the window. These areas include the menu bar area, command area, work area, and message area. OLIT has no equivalent widget.
(none)	XmPanedWindow	Motif XmPanedWindow widget provides a way to lay out its children in vertically oriented panes. Each of the panes has a sash that can vertically resize the pane. OLIT has no equivalent widget.

Study the Target Environment

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 Run-time and Development Environments: See "CDE Documentation" for a listing of all CDE documentation that SunSoft provides. In addition, the desktop applications each have online help volumes.

GUI Development Tools

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.