Antony Fountain co-authored the newly updated Volume 6B: Motif Reference Manual, 2nd Edition with O'Reilly editor Paula Ferguson. The manual is a companion to the Volume 6A: Motif Programming Manual, part of O'Reilly's X Window series. In this recent interview with O'Reilly Web Reporter Lori Houston, Fountain champions the prevailing benefits of Motif and compares it to newer, higher profile toolkits.

Houston:

What's the history of Motif?

Fountain:

It started out as collaboration between Digital Equipment Corporation (Compaq), Hewlett-Packard, and other companies to provide a common interface toolkit for the X Window System. The independent group formed to maintain and develop the software has gone through several manifestations: from "X/Open" through "The Open Software Foundation" to its current name, the "Open Group."

Although it seems to have been around forever, Motif has become the prima facie native toolkit on Unix. Every single major operating-system vendor supports and supplies it. It's been ported round more Unix platforms than any other toolkit. Motif is simply the native Unix windowing toolkit.

Houston:

Where and how is Motif being used most commonly these days?

Fountain:

Motif is used throughout the industry, but its main users are the Fortune 500 commercial organizations and leading industrial concerns that produce large-scale, mission-critical, industrial-strength, internationalized, leading-edge software. It's also used heavily by the operating-system vendors themselves, in producing their own development environments.

Houston:

Is Motif experiencing any kind of resurgence associated with the current Linux wave?

Fountain:

Motif is as alive and well as it ever was, but the direction Motif is taking is considerably more silent than the Linux community. The problem here is whenever a piece of public software is released for Qt or GTK+, the backers of these toolkits make sure that everyone knows about it, in order to further their own toolkit and reputations. There seems to be a weekly announcement on slashdot that program X now has a GTK+ binding, for example.

However, most large-scale commercial companies don't like bandying their names about in public, due to their proprietary nature. When the product with which I am most closely associated (X-Designer, the Motif GUI builder) is sold into some large organization in multiple copies, absolutely no press announcement is made of the fact. It's a contractual thing: developers sign on the dotted line not to mention that they used Motif on some application. They keep this to themselves, but the core graphical technology is Motif. In many of these companies, there's not a single line of Qt or a Linux box in sight.

Motif remains resilient precisely because the Linux culture is entirely foreign to how the Motif community works. Secrecy, intellectual property rights, and long-term, large-scale projects do not marry well with open source public announcements. The essential nature of commercial software is anonymity. As commercial engineers, we don't plug our own names or reputations with the software that we sell. There's nothing in X-Designer or the manual sets to say who wrote it.

The biggest single group of large scale developers with Motif is not the operating system vendors producing various workbench products, but very large commercial companies who make and distribute very large Motif applications in-house for their own purposes. Motif is very much alive and well: it just isn't making public noise because that isn't the name of the game. Millions of lines of Motif get written and not one word about it leaves the company doors.

Houston:

Does Motif offer anything that some of the newer toolkits--such as QT for KDE or GTK+ for GNOME--don't?

Fountain:

For overall coverage, user and programmer configurability, environment development, and commercial support, there's nothing to match Motif other than Java. There are things Qt in particular does better than Motif: it is nicer to program with, for example. As a language, Motif does show its age. However, that doesn't make a hoot of difference when you have an end product to produce.

The nature of the game here is completeness. You have to look not just at the nature of the language itself--which seems to be the main focus of the Linux toolkits--but what you and your customers/users can do with the end product. One of the concerns I personally have with Linux is that the toolkit is not the product. It does not matter how elegant a toolkit is in terms of programmer taste if at the end of the day the product derived from the toolkit is shorn of customizability, internationalization, attribute configuration, or a standardized way of working. The commercial world writes product for customers and users; the Linux community writes software for programmers.

Where are the Qt/GTK+ style or user's guides, for example? No such beasts exist. The nature of the software being produced with Qt and GTK+ is yet more software for programmers. KDE, GNOME, and the like aren't about products and customers at all. Commercial concerns look for more in a system than just programming elegance. There is no question that it would have been much better if Motif had a programming front end like Qt. But the primary question is what can be done with it. For example, I could write a C++ front end onto the Motif classes in a week, and many companies have done this independently. As a native toolkit for producing products, there's still nothing to touch Motif. If you plug a C++ front end onto Motif, Qt has precisely nothing.

If we consider Qt, GTK+, and Motif on a component-by-component basis, there is simply no comparison: the Motif components are considerably richer in attribute support, and the range of available components--whether built in to Motif or available as third party plug-ins, far exceeds anything that the Linux toolkits can offer. I have personally integrated over 650 Motif-compatible components into the X-Designer GUI builder.

Indeed, there is no commercial GUI builder for Qt or GTK+. There are a number of private programs available, but as far as companies go, this is a no-no because it fails to guarantee any kind of continuance, stability, or development. Compare this with the Open Group's seven-year license for maintaining Motif, guaranteed by contract. Continued development is absolutely guaranteed. The same cannot be said about Qt or GTK+. The commercial infrastructure just isn't in place.

Houston:

You make a point of mentioning in the Motif Reference Manual that many of newer GUI toolkits do not include the Xt layer. What is this and why is it so important?

Fountain:

Xt is a library of support routines that define a component model: what a widget is, how to interface to it, query its attributes and the like. It also provides standard resource support and internationalization methods. But Xt is not the central issue; a component model is. There are several implications if a language fails to provide a component model:

• Developers cannot acquire third-party components and plug them into the system. There is nothing that allows the new components to talk to the old. This can be done with JavaBeans and Xt widgets, but it's not possible with Qt components that have to be plugged in at the source level. The developer has to hand code everything, which translates into serious scalability issues.
• Developers cannot integrate their new components into their favorite GUI builder because nothing allows the builder to query the object. In the absence of an external object description language, a builder tool cannot present resource/attribute panels for the object, dynamically alter the attributes, and thereafter generate code for the component. No such external description language exists for either GTK+ or Qt. Motif has UIL/WML, but doesn't actually need these to provide the above introspection because everything necessary to integrate an object is present and deducible from the object itself. JavaBeans are designed with introspection so that developers can point their favorite GUI builder at them and they load just like that.
• In the absence of an object instance/class parse tree that the component model implies, developers are debarred from constructing not just GUI builders but any dynamic tool that works upon the instance hierarchy of a running application. Editors can't be written for Qt, for example. Without a component model, any program written with the given toolkit becomes proportionately that much more difficult to reverse engineer. When the next paradigm arises after Qt, it will be almost impossible to construct any automatic tool that can convert the Qt object into canonical form.

Compare that with something like X-Designer, where, using the parsable Xt dynamic instance/class hierarchy, developers can map a given application through to Java, MFC, or whatever dynamically, without recourse to any kind of source. The X-Designer Motif save files are therefore future-proof in a way that Qt sources are not. Using the canonical form derived from the Xt hierarchy, we can maintain a code-free view of the application, which provides an escape route for the application. If customers need to go to Java from Motif, they can. If they need to go to MFC from Motif, they can. But if they need to go from Qt to an alternative, they can't.

Houston:

Is anyone working on a component model layer for Linux toolkits?

Fountain:

Actually, GTK+ now does have an embedded component model that satisfies the requirements of the built-in component range. (I wrote otherwise in the book, because that was accurate at the time.) The point I was trying to make is this: In Motif, the resource type conversion mechanisms (XmRepType) are open, enabling developers to create third-party components whose resource attributes are foreign to the Motif toolkit. Developers can also use the resource conversion mechanisms (XtConvertAndStore) so that a GUI builder can load and understand the types without any kind of external configuration, regardless of where the component comes from. This isn't true in the GTK+ model: the resource typing is not truly open, so a GUI builder cannot be written so that it understands how to handle a foreign type from a third party component. Beyond knowing that the type is foreign, how to convert the data between component and string form and back again is not fully deducible. And this would make any attempt to provide an integration for the component concerned with your chosen GUI builder worthless. Thus, there still is no third-party component market for GTK+ because there's no complete way to slot them in.

Houston:

Beyond the component model issue, Motif is said to be the only native toolkit for Unix that supports large-scale internationalized applications. Why is that important?

Fountain:

Xt/Motif provides built-in standard methods for user customizability of components, which includes built-in internationalization capability. The internationalization issue may prove to be a key killing point for Qt/GTK+. GTK+ text components do not include multi-byte support, so it won't run properly in Japanese, for example. But the whole world does not speak (American) English; indeed, most of it doesn't. That debars Qt/GTK+ from a whole range of domains where full, internationalized support is a must. Although there is some internationalization provided in Qt/GTK+, it misses some of the main points. Even layout is a language-specific issue, for example. Motif fully covers this with its ability for components to switch left/right organization at the turn of a resource. This can't be done in Qt or GTK+.

Locale, language, and resource customizability supplied by the Xt mechanisms is the standard for X environments. Xt also enables developers to maintain backwards compatibility with an existing application base. If Qt/GTK+ had been Xt based, there would be components that could be seamlessly loaded into any GUI builder to replace the existing Motif set. It would even be possible to produce an automatic tool to do this. But since QT/GTK+ isn't Xt based, this can't be done. And the entire commercial world is not going to be able to replace millions of lines of automatically generated Motif interface code with hand-written Qt/GTK+. Legacy code exists, and it has an inertia all of its own. The existing Motif/Xt application base is huge.

Another critical aspect of Xt related to internationalization is the level of logical software layering, which is entirely absent from the Linux toolkits. Xt is devoid of hard-coded look-and-feel: it's an enabling technology out of which any number of alternative interface styles can be designed. Motif just happens to be one of them. There's also others, such as Athena. In Qt, however, the technology and the interface look-and-feel are embedded in a single library. This means that when the world of GUI design moves onto an alternative paradigm, the entire Qt technology will require a top-down revamp. But even if Motif passes into history, developers can still keep the core standard internationalization support for the replacement interface kit.

Houston:

Would you summarize what is new in this latest edition of the Motif Reference Manual?

Fountain:

Obviously, the whole book was updated for Motif 2.1, so it covers the new widgets, like ComboBox, Container, and Notebook, as well as all the new functions for things like render tables.

The book was written with the complete reference sources rather than the Open Group documentation, which we only referenced to see what the OSF has documented. What they document, we document. However, we also cover what they don't. This latest manual is also more complete now because it includes items like the XmIm functions and dedicated sections for the Uniform Transfer Model. Motif Reference Manual now reflects the exact nature of the Motif toolkit as implemented--warts and all--whatever the programmer really needs to know.