Building professional Motif GUIs on Linux is only a drag and drop away.

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 made that statement to many people, ranging from experienced X Windows programmers to neophytes slaying the dragons on a daily basis. I have never been presented with an argument against my claim. Cross-platform considerations make it even more difficult.

If you’re like many IT shops around the world, 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 make the move to a GUI-based client interface.

So what do you do to keep the users happy, maintain programmer efficiency, and keep internal IT costs in check? Getting all team members up to speed on GUI development is difficult and hiring a small number of GUI-specific experts to spread around the running projects is expensive and inefficient. Adding to the dilemma, you just have to accept the fact that basic Windows programming with MFC and Microsoft Visual C++ is a breeze for your programmers. After all, to put a message box on the Windows screen is as simple as:

Status = MessageBox (“Hello, World”, “Hello world application”, MB_OK);

In contrast, almost every text book you can find on the subject of programming on Linux expresses cautions in various degrees. One text suggests that you should only consider writing a GUI for a program 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 picked up to date has made me believe that you need several years of experience in navel study on a mountaintop before you could hope to make something actually function on X Windows or any of its many descendants.

We started our work with BX PRO by following the tutorial, which develops a simple address book interface step by step. Like all BX PRO documentation, the tutorials are accessible via the Help menu and are provided in Adobe Acrobat format. At first this was a problem because we had to configure BX PRO to use our pdf reader. Of course if you cannot access Help, how do you find out how to configure it? Fortunately, BX PRO generated an error message when we tried to access any of its documentation that provided instructions on how to setup the PDF reader.

We wound up with the interface we intended and that interface closely resembled the stated goal of the tutorial. Nonetheless, we found 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. When we last reviewed BX PRO almost two years ago, we found the tutorials lacking some of the detailed steps that novice developers might need to complete their sample user interface. We’re happy to see that the folks of ICS accepted our criticism and have substantially upgraded their tutorials. After following the tutorials, we wound up with the interface we intended and that interface closely resembled the stated goal of the tutorial.

With most visual GUI development tools, you can only 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.

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, re-make the classes, switch into “class” mode, and manipulate the class definition. When you change back to “instance” mode, the changes to the class are automatically propagated to the instances you created. This dual mode approach can be confusing at first, but is also very powerful once you get used to it.

After working with the BX PRO interface for a while, 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 and mostly obvious.

BX PRO is able to 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.

The argument as to whether compilers can generate better code than humans has been raging since the first compiler was built. There are several corollary questions that are often pushed aside in that discussion. The major one is raw programmer productivity. While an experienced programmer might be able to squeeze a few 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 than 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 multi-tiered 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 PRO 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. Furthermore, waiting a long time for the attention of one of those few GUI experts only to find that they make an error at a seemingly innocent point is unacceptable. 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 PRO as OpenBench Labs views the product.

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. Some aspects might have been correct while other details might have been lost or forgotten. If the programming investment is relatively small, the cost of re-working the interface is correspondingly small. However, if the programming investment is significant, the cost of re-working the interface might be prohibitive.

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 sub-style can be created and that style can be applied to the necessary objects. As with heredity in C++ classes, all the characteristics of a BX PRO 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 see and use ICS BX PRO differently. Some will see it as a lifeline thrown to them 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 embrace BX PRO as a teaching tool, to teach programmers the course-grain aspects to GUI programming. We expect most enterprises will find ICS BX PRO to be a powerful tool that will help them to develop GUIs and maintain standards between Linux and multiple flavors of Unix.