| OPENBENCH LABS SCENARIO |
Under examination
Motif GUI development tools
What we tested
ICS Builder Xcessory (BX) and BX PRO
www.ics.com
For more information on Motif, go to: www.motifzone.com.
How we tested
Development workstation running Red Hat Linux v7.0
www.redhat.com
Key findings
- BX allows even a relatively new Motif/X programmer to design the layout and implement the details of the interface visually.
- Dragging and dropping controls onto the workspace assigns their parentage by their position in the hierarchy chart.
- When a class is generated in the GUI hierarchy, changes can no longer be made in the "instances" mode and the class must be "unmade."
- The tutorial instructions are not crystal-clear and it is easy to run off the rails when learning the product, its methodology, and the programming style required of Motif.
|
Did you ever pick up a book on developing GUIs for Linux? Did you cringe at the volume of code required to put the ubiquitous "Hello, World" string into a message box on the screen? GUI development on Linux (or Unix) is difficult. I have said that to many people, ranging from experienced X-Windows programmers to neophytes slaying dragons on a daily basis.
Nobody has argued. Cross-platform considerations make it even more difficult.
If you're like many IT shops , you have legacy command-line interface code written on older Unix and proprietary operating systems. What's more, your users started complaining long ago about the lack of friendliness of the command line and demanded you move to a GUI-based client interface.
So what do you do to keep users happy, maintain programmer efficiency, and ensure that internal IT costs remain in check? Getting all team members up to speed on GUI development is difficult; hiring a small number of GUI-specific experts to spread around to projects is expensive and inefficient. Moreover, you just have to accept that basic Windows programming with MFC and Microsoft Visual C++ is a breeze for programmers. After all, putting a message box on Windows is as simple as:
Status = MessageBox ("Hello, World", "Hello world application", MB_OK);
On the other hand, almost every textbook you find on the subject of programming on Linux expresses caution in various degrees. One text suggests that you should consider writing a GUI for a program only if the users cannot possibly fathom a command-line interface. The first line in the preface of a text on the subject of GNOME interface programming cautions, "Programming with GNOME is no simple task for the uninitiated." Every text I have seen to date has made me believe that you need several years of experience in navel study on a mountaintop before you can hope to make something actually function on X-Windows or its many descendants.
Nonetheless, the history of the Unix world is that every person-whether academic, practitioner, or fiddler-who has a slightly better idea of how to solve one particular aspect to a problem will build that better mousetrap. Out of this came X-Windows as the transport layer for GUIs.The problem is that relatively little effort was expended towards defining the programming interface and methodology of how pictures and windows are described.
This situation has given rise to a multitude of "libraries" that present a somewhat consistent programming interface above and hide varying degrees of complexity in the detail level below. At the same time, the packages that succeeded all allowed the programmer to bit-twiddle, while making the interface style consistent and useful. The problem that these libraries fail to address is that of helping the programmer to design the interface. They deliver a multitude of raw materials but the construction, techniques, and details are all left to the unfortunate student, or, worse, to the programmer expected to actually present running code for an enterprise.
This month, OpenBench Labs took a close look at a product that will increase your developers' productivity and deliver the goods. Builder Xcessory from ICS (Integrated Computer Solutions, Cambridge, MA) is a GUI builder of extraordinary capabilities. The tool is practical and useful for building real-life code for production systems. It will teach people how to build applications and empower the more adventurous to withdraw from the humdrum and focus on the specific, to any depth they care to dig.
The design goal of ICS Builder Xcessory (BX) and BX PRO is to allow the programmer to design and create a Motif GUI visually. As one of the more popular X interface options, Motif is used on more than 200 hardware and software platforms and is hailed by the IEEE 1295 standard. ICS BX is supported on a wide range of operating systems, including Sun (Solaris and SunOS), IBM's AIX (RS6000 and PowerPC), HP-UX, SGI's IRIX, Compaq Tru64 UNIX, and OpenVMS, as well as most Linux platforms.
BX allows even a relatively new Motif/X programmer to design the layout and actually implement the details of the interface quickly. BX can then be used to make small adjustments and write template code, or the programmer can roll up his or her sleeves and get to bit-twiddling. Bottom line, BX allows programmers to be more quickly productive than they would be by doing all the implementation by hand.
We started our work with BX by following the tutorial, which develops a simple address-book interface step by step. We wound up with the interface we intended; that interface closely resembled the stated goal of the tutorial. Nonetheless, we found that some details were missing or ignored in the tutorial guide. While it is certainly true that most of the application coding is "detail-level" material, we believe that a fully functioning sample would be preferable.
With most visual GUI development tools, you build the GUI directly on the screen in an almost WYSIWYG fashion. You drag a control to the screen and drop it in the appropriate place. You then select multiple objects and align them on the screen. With BX, you build the interface on a hierarchy-tree diagram. When you drop controls onto the workspace from the palette, you assign their parentage by virtue of where you drop them. As you develop the interface, the hierarchy chart gets quite complex.
When you generate a class for a section of the GUI hierarchy, the hierarchy disappears from the "instances" view. In order to view that section of the GUI, you must change views to the "classes" view. Once the class has been "made," you cannot make all the changes you can in the "instances" mode. In order to make those changes, you must "unmake" the class, make the changes, and
re-make the classes.
After a while in working with the BX interface, the process of developing an application interface became intuitive. The idea of drawing a "map" of the application, then assigning styles and setting the particular properties of the individual controls and widgets is one that we believe will appeal to the programmer mentality and become natural.
BX can produce generated code in native C, C++, or Java, which leaves development management free to keep their chosen languages. This does not, however, mitigate the need for the target machinery to have the appropriate libraries and supplemental support structure installed. Any target system will still need to have the Motif libraries.
More importantly, BX supports the programmer though all phases of a project and reliably preserves modified code. To ensure code is added correctly, the generated code contains delimiting comments intended to surround the custom code added by the programmer. In this way, BX actually supports far more than just the code that implements and supports the GUI.
One of the problems with many GUI superstructure products on Linux and broader Unix platforms is that most of them do the easy part and leave the programmer to figure out the rest. At some essentially unspecified point, the "helper" tool fails and the programmer is left holding the bag. That point of failure is generally where the pressure is greatest: within the last 10% of the project. The programmer is then left with no choice but to delve into sometimes ugly code.
BX also allows the addition of code for any and all purposes. The programmer might, for example, choose to change the interface dynamically in the event that some aspect to the program state changes in the course of execution. By using BX's styles and modifying the generated code, the programmer might choose to alter the choices available in a menu or change some aspect to the appearance of the GUI.
The argument as to whether compilers can generate better code than humans has been raging since the first compiler was built. Several corollary questions are often pushed aside, the main one being raw programmer productivity. While an experienced programmer might be able to squeeze a couple more instructions out of a loop than a compiler, it likely takes the human a few thousand times as long to get into the text editor as it takes the compiler to generate the code. The efficiency gained from the savings might be significant in some parts of the operating system kernel or in an application's inner processing loop, but in these days of superpipelining and huge multitiered caches, it is unlikely to have a measurable impact in reality.
A similar argument could be made with regard to whether an experienced programmer could write "better" code than BX generates. I doubt that even ICS's best would deny that they could easily write better code than their product can generate. However, the issues are a little more far-reaching in the case of GUI design and implementation.
The ability to quickly add a new control (widget) to a GUI is of paramount importance to the practical realities of enterprise IT departments. Having a long queue of GUI modifications waiting for the attention of one or two experts is not acceptable in most industries. Spreading the workload and empowering relatively junior programming staff to make modifications quickly and reliably is far more appealing. This is one of the major advantages of BX.
Consider the GUI development cycle. Typically, the developer works with the user to define specific needs of the user interface. The two views of the needs of the users might not be fully reconciled in the first draft of the interface. If the programming investment is relatively small, the cost of reworking the interface is correspondingly small. However, if the programming investment is significant, the cost of reworking the interface might be prohibitive.
BX walks the fine line between making the implementation of the interface easy and allowing an experienced developer to make adjustments. BX allows the programmer to define and share multiple "styles," which are partitions of resources into categories and subcategories. In much the same way that a C++ class can be subclassed, BX styles can also be implemented hierarchically.
By developing a "library" of styles, the programmer can apply similar X entities-resources-to a collection of controls or widgets. If a new widget requires a slight difference in appearance or behavior, a substyle can be created and applied to the necessary objects. As with heredity in C++ classes, all the characteristics of a BX style are inherited by that style's child styles. The details of the differences are then applied to the child styles so that only those aspects are different.
Programming organizations will use ICS BX differently. Some will see it as a lifeline in the turbulent seas of GUI programming. Some will see it as a transition tool to get them from the Windows and Visual Studio environment to a point of productivity in Linux. Others will use BX to teach programmers the coarse-grain aspects of GUI programming. We see most enterprises finding ICS BX to be a powerful tool that will help them to develop GUIs and maintain standards between Linux and multiple flavors of Unix.
| 
