By Dave St.Clair
Until recently, the biggest headache for a developer of workstation-based applications was porting between the various flavors of Unix and different releases of the X Window System. In the end, such ports typically were handled by a few ifdefs and specialized functions. Today, however, with the emergence of Pentiums and other powerful PC systems, users want to run portable apps on their Windows "workstation." ifdefs may have been fine for working with different Unix flavors, but they are inadequate when moving between more radically different platforms. For true cross-platform support, more sophisticated tools are in order.
GUI (graphical user interface) builders are wonderful tools for constructing user interfaces with intuitive WYSIWYG interfaces. To add a button to a window, simply drag a button object from a tool palette and drop it in the appropriate location. Adding hooks (callbacks) to your custom apps is typically done with a click of the mouse and a little typing. But, since standard GUI builders (such as X-Designer, UIM/X, or Sun's DevGuide) focus on GUI elements for a single platform, they lack the portability, flexibility, and wider range of widgets common among cross-platform development tools, which encompass all the features of a GUI builder and extend to handle multiple operating and windowing systems and provide true platform independence.
Most of the tools in this growing field take one of two approaches to solve this problem: layered or emulated.
Layered products access the target platform's native GUI toolkit and therefore are more likely to conform to the platform's native look and feel. The XVT Portability Toolkit from XVT Software (Boulder, CO) follows this route. Emulated products, on the other hand, access the low-level calls of the platform without going through the native toolkit. The cross-platform product itself is responsible for look-and-feel compliance -- which means an emulated product's look and feel may be slightly different than the native toolkit. Emulated GUIs can provide any of the supported user interfaces on any supported platform (allowing, for example, a Mac-like interface on a Unix workstation) and can also be more efficient than the layered products -- or even the native toolkit -- since emulation involves a complete re-implementation that avoids an entire level of software. Furthermore, by providing a single interface for multiple platforms, emulators let developers provide only one user manual and one set of training materials for all platforms and let users easily move among diverse systems. Such products include Galaxy from Visix Software (Reston, VA) (which would have been included in this review, if it were not for Visix's refusal to participate despite extensive negotiations) and Open Interface Elements from Neuron Data (Palo Alto, CA).
Neuron Data's description of its Open Interface Elements product as a "GUI application development tool" doesn't highlight its strength as a cross-platform utility. Open Interface Elements reaps impressive results with the emulation approach. The Open Interface (OI) environment lets developers create GUIs with simple point-and-click operations using the Open Editor, and easily incorporate them into their apps. In addition to the normal toolkit widgets, Open Editor has a comprehensive set of interface widgets including tables for spreadsheet operations, tree browsers, business graphics, color icons and images, and multifont text fields. Open Editor lets users easily integrate their own custom widgets, and it provides complete and uniform isolation from the non-GUI components of a given platform.
Although developers are free to write portable code using the robust Open Interface API, Open Editor's set of graphical interface editors (a.k.a. resource editors) beckons. Developers can use these editors to lay out windows and customize the widget set. One editor window exists for each type of resource.
The most important editor, called the Window Editor, contains customization options, a widget selection list, and a scrollable work area for laying out your windows. Individual resource editors may be accessed on the fly by double clicking on any displayed widget.
Open Interface uses resources to modularize many parts of the application code. Resources store all the persistent field information for a particular item. Separating resources from the application code offers several advantages. For example, string resources let developers prepare their products for various international markets without having to recompile their code. Resources also benefit from using a set of routines that are well defined, efficient, and -- most importantly -- generic. Thus, code assets can be shared more easily among different parts of the same application and among different applications.
Legacy code can be used unchanged unless it is screen-oriented. There is nothing preventing you from mixing Xlib/Motif calls with OI; it would just present a maintenance nightmare. Of course, you must ensure any legacy code is portable across the desired platforms.
One feature that sets Open Interface apart is its scripting language. Entire applications or portions thereof may be developed without leaving the cushy world of Open Editor and without using C or C++. The script language is comprehensive and extensible. Developers attach scripts to widgets within the window editor via a menu item.
A script for a widget comprises a set of handlers, where each handler is composed of statements that will be executed in response to a given event. These events usually are not the full set of window events available to the system but are the events relevant to a particular widget. For example, a button typically doesn't notice mouse motion or direction, but whether the mouse is clicked while the cursor points to the button.
Developers can go beyond Open Interface Elements' scripting language by calling C/C++ functions. Scripts may be called directly or built on the fly in C/ C++ code. One convenient use of scripts is in the creation of rapid prototypes as a means to get faster user feedback.
It is not surprising that Open Interface provides a good object-oriented environment, since the design of GUIs falls naturally into this domain. OI's resource editors are classed from a common parent, so editing of any resource is done similarly. This helps in mastering the tool. One of the big advantages to object-oriented programming is code reusability, and Open Interface's modules and resources form the basis for creating a variety of reusable interface widgets. The managers defined for these widgets are generic and powerful enough to handle most every instance.
Code sharing within Open Interface is illustrated by the handling of events and errors. By encapsulating these handling tasks into dedicated modules, developers can make these services available to all the resources and widgets of an application. Because event and error handling must be active and ready at all times, it makes sense to share this code instead of having to rewrite it into the managers of individual widgets.
Open Interface's OO technology leverages the development effort by allowing reuse of objects and methods across different applications. Newly formed objects that support advanced functions can inherit attributes from existing objects. New functions can be encapsulated incrementally, or objects modified independently, without changing other existing objects. Open Interface provides a unifying structure for holding and filtering relevant data, regardless of its origin, using a dynamic, common object representation and pattern-matching technology.
With the current emphasis in the development world on C++, it is often presumed that OOP is not possible in ANSI C. To this end, Open Interface provides OO interfaces for both C and C++ without crippling either language with a least-common-denominator approach. Actually, full support for C++ wasn't available until the current release.
Also new with 3.0, the standard Open Interface widgets are C++ classes. This means that subclassing off these widgets is simply a matter of declaring a new class with an OI class as a parent.
You'll need about 50 megabytes of free disk space to install Open Interface Elements. Installation on a souped-up SPARCstation IPX (withWeitek's SPARC Power ÁP) with 32 megabytes of RAM took 25 minutes (and -- gasp! -- Neuron Data novelly suggests that a user other than root install the software).
Documentation is thorough: two volumes of API reference manuals, a developer guide, a user guide, and a scripting guide/reference. The user guide is extremely well done and includes a 200-page step-by-step primer on how to create an application -- complete with complex custom widgets.
Neuron Data provides support via telephone and an electronic bulletin board and offers training courses.
Running with Open Editor
At the center of the Open Interface development cycle is Open Editor. The Resource Browser, Open Editor's main window, is divided into two screens: The left displays the overall tree diagram of the application resources/widgets; the right shows a portion of the tree in greater detail. When creating a new application, you simply select the New Application menu option and the Resource Browser creates a simple tree diagram and pops up the Window Editor.
Once in the Window Editor, you can create various GUI components of the applications by point and click and drag and drop, and you can test the interface without leaving the Window Editor. When the first round of edits are complete, the window is saved as a library.
When saving the library, Open Interface helps create a makefile for any or all the desired platforms. Developers can then use the GUI editor to add any custom make commands.
The final output of a save comprises a makefile, various resource files, and a C/C++ file. The C/C++ file contains a simple main program and any widget callback functions. The file may be modified by the developer outside of the Open Editor, provided all changes occur in specially designated areas. These areas are clearly marked USER CODE.
The resource files may be edited by hand or via a Resource Editor from Open Editor. A recompile is not necessary when changing the resources. A provided localization awk script migrates resource files to various international flavors.
The application may be compiled against one of three libraries: debug, static, or dynamic. The debugging library yields a wealth of information when that rare programming methodology error occurs. The static libraries are available, but we recommend using the shared libraries (if your platform supports it). The static executable size is huge -- a simple Hello World application took up 3 megabytes of disk space; the shared library version was a paltry 20,000. Of course, this is disk-image size; your mileage may vary.
On first glance it appears callback functions may be changed only via your favorite editor -- completely outside Open Editor. This was the case in previous versions, but with the advent of scripting, you can now set your callbacks as scripts within the Script Editor. The script need only consist of a couple lines that call your own C or C++ routine. Although this use of scripts isn't documented, it worked flawlessly.
Open Interface provides a few classy widgets that merit some extra attention. Its list-box widget, for example, implements features to support a complete spreadsheet or data table, not just the standard (and boring) simple scrolling list of the traditional toolkits. Each independent cell of the list box has its own header and supports selection, full graphics and custom drawing, in-cell editing, and resizing.
Neuron Data has provided a spiffy Chart Object capable of pie, bar, area and line charts, and scatter plots in either color or monochrome. It can be linked easily to the list box (or any other object) to provide real-time graphical feedback. The Chart may also be live -- allowing for selection and dragging of graph elements. The Chart can send output to your screen or printer.
Hypertext operations can be easily added to any Open Interface application from simple text boxes to full scrolling text areas. A simple help system built on this system also is provided.
Support of custom widget development is not a unique feature, but Open Interface's three levels of customization certainly has made it simple. The first level adds functionality to an existing widget by editing the C or C++ template created by Open Editor. This applies only to widgets placed in a window; icons and images are excluded. The second level creates simple subclasses that are based solely on existing Open Interface classes. This can be accomplished within the resource browser by selecting the Add Subclass option.
The third level of customization calls for creation of a custom resource or a custom widget -- a complete, new resource class that is fully incorporated in the Open Interface development environment. This is a lengthy but straightforward task best done by an experienced Open Interface developer.
Tools providers often fail to facilitate effective cross-platform drawing. Open Interface breaks this mold by including a good 2-D drawing model. It provides a higher level of abstraction than the X11 or PostScript drawing primitives, without taking away any needed functionality. The drawing module should easily handle the cross-platform graphics of the average application. Still, more advanced 3-D and imaging apps will have to create their own custom drawing resources (which could be classed off the existing 2-D model).
All told, Open Interface Elements provides all the widgets of standard GUI toolkits (Motif, Windows SDK), plus widgets to isolate operating system dependencies, and some snazzy GUI widgets that aren't found in your basic toolkit. The package is well designed for those developers working on true GUI/ graphic-intensive cross-platform (Unix/ Macintosh/Windows) applications, and is robust enough to develop commercial-grade products. Compared with using two or three GUI builders (one for each platform) at $2,000 or $3,000 each and then still having to ifdef the heck out of the back-end code, OI Elements easily pays for itself in training and development time. If, however, your target application is likely to stay on one platform or your user interface is nongraphical, the cost of learning a new API might not be worth the investment.
Neuron Data offers two add-ons to the Open Interface product: C/S Elements and Smart Elements.
C/S Elements adds a data-access layer to the base Open Interface, which provides transparent access to data sources via extensible database drivers. C/S Elements provides direct (native API) support for Oracle and Sybase and ODBC access to Informix, CA-Ingres, HP Allbase/SQL, and other servers. It also offers full read and write access to hierarchical, flat-file, and object-oriented databases.
Smart Elements is based on Neuron Data's own expert system tool, Nexpert Object. This module lets developers incorporate domain knowledge into the application without dealing with the complexity of a standard language.
Also, for the poor souls who still need ASCII applications, Open Interface provides a portability to ASCII and DOS character-based screens. Obviously, graphics and images fall by the wayside, but most other widgets come through with a reasonable representation.
Bringing it home
We have one big complaint about the Open Editor: There's no undo command. All the other basics (cut, copy, paste) are there, but no identifiable undo.
When compared with native toolkit implementations, Open Interface fares well and perhaps delivers the best look-and-feel compliance across the different platforms (Open Look, Motif, Windows, Presentation Manager) of any of the competition. The Open Look appearance isn't as good as XView toolkit-based applications (such as Sun's OpenWindows desktop tools) but is much better than those Open Look applications developed with the OLIT toolkit. The Motif and Windows implementations are indistinguishable from the originals.
Note that the Open Interface hardware requirements apply to runtime users as well as developers. The Open Editor ran just fine on a SPARCstation IPX with a Weitek Power ÁP accelerator and 32 megabytes of memory under Solaris 2.4 but was almost intolerably sluggish on a SPARCstation IPC with 24 megabytes of RAM. On Unix development boxes, start with at least 32 megabytes and no less than a SPARCstation 2-class system. For runtime, apps created with Open Interface should perform similar to those developed natively (with X11R5/Motif, Windows SDK, etc.) for the various platforms, although a bit more RAM may be required.
Object Interface Elements is a solid cross-platform product. Open Editor is a full-featured GUI builder, simple to use, yet provides sufficient flexibility to not be in the way of an experienced user. The Open Interface API is complete and, when coupled with the extended widget set and optional C/S Elements, could easily meet the requirements for any commercial-grade cross-platform, multiple-database application.
About the author
Dave St.Clair (firstname.lastname@example.org) is project manager of Software Development for Western Geophysical Exploration Products, where he leads a team of 20 developers. He has been developing on Unix systems for 12 years and began using C++ during his tenure at AT&T Bell Labs.
A few companies are trying to leverage existing platform toolkits and extend the support to non-native environments. Nutcracker from Data Focus implements the most common Unix SVR4/POSIX function and systems calls in a Windows NT/Windows 95 environment. Nutcracker also includes the MKS toolkit for developer tools (Lex, Yacc, make, etc.).
Nutcracker also supplies DLLs (dynamic link libraries) for X11R5 and Motif for the Windows environment, although a PC X server is required. Data Focus provides the AGE Logic X server as an option.
If you're trying to go the other way (from Windows to Unix), at least one company may have what you're looking for. Bristol Technology's Wind/U is an implementation of the Windows API under Unix/Motif. In addition to supporting the core Windows functionality, Wind/U includes custom widgets so applications can utilize multiple document interfaces, dynamically linked libraries, and a PCL4/PCL5 printer.
1270 Oakmead Pkwy., #310
Sunnyvale, CA 94086
Portable implementation of Microsoft Windows API on Unix/X11. Doesn't require Motif, but sports a Windows and Motif look.
12450 Fair Lakes Cr., #400
Fairfax, VA 22033
Provides a complete Unix-style development environment with standard Unix libraries on Windows NT/Windows 95. Requires a PC X server for runtime.
241 Ethan Allen Hwy.
Ridgefield, CT 06877
Portable implementation of Microsoft Windows API on Unix/X11/Motif. Includes several migration tools.
XVT Portability Toolkit
4900 Pearl East Cr.
Boulder, CO 80301
800-678-7988, 303-443-4223 email@example.com
The granddaddy of all cross-platform tools, XVT takes a layered approach that has improved in the last year.
2065 Landings Dr.
Mountain View, CA 94043
Full C++ class library that includes an optional GUI builder. Builder is not as comprehensive as ND/XVT/Visix.
405 South 100 East, Second Flr.
Pleasant Grove, UT 84062
800-638-8665, 801-785-8900 firstname.lastname@example.org
Full C++ class library with integrated GUI Builder. Includes source.
If you have problems with this magazine, contact email@example.com
Last updated: 1 March 1995.