X-Designer

Code generation is the core operation of every GUI builder. Though X-Designer's friendly interface leads you through the GUI design, code generation is the reason you bought it. I think the Motif/C combination for Unix/X workstations is the native configuration. I tried to create a few small GUIs; they all worked and compiled without warnings. All I had to do was manually set the location of the Motif libraries and headers in the Makefile, since I keep them in the /client/lesstif directory. The same applies for the C++/Motif combination, which also worked flawlessly.

Portability is an important issue today, so I set out to explore the Java and Microsoft Windows code generation options. I had a design targeted for a Motif/C combination, and I tried to change it to Java code. Of course, the callback code was useless; I didn't expect X-Designer to translate my C code into Java code, but links also work in Java. The prerequisite for Java designs is to include the path to a set of Java classes, which are provided with X-Designer, in the CLASSPATH variable. The classes are put into the package called uk.co.ist.mwt. They provide components which have counterparts in Motif but are missing in Java. There are also some widgets which are added to the standard Motif set to implement some Java components not present in Motif. They are container widgets, such as the Card Widget, Flow Widget, Border Widget, Grid Widget and GridBag Widget. This enables the WYSIWYG development of Java applications.

Changing my test design for Java required toggling the Java compliance toggle-button under the Module menu. X-Designer then checks the current design, giving you messages about any non-compliant parts. Sometimes the “Fix” button will be enabled, allowing you to trigger the automatic fix for Java Compliance; otherwise, you have to do it yourself. If you know about Java and Motif, the messages generated by X-Designer are more than enough to give you a clue about what is happening. I don't know much about Java, but I know enough to make the design Java compliant within minutes. The Java code generation dialog is different than the C/Motif one in that you must specify which file to create. A file for every class, the top-most application class file and separate sources for string, color, font and other objects are included. Using JDK 1.0.2, I compiled and ran the application without any problems as a Java application. I could have built a Java applet, in which case additional constraints might have popped up.

All of X-Designer's dialogs use the same convention of marking the resources and settings which are relevant for Java. Whenever there is a steaming coffee cup icon next to the resource, it means that it will be honoured in Java code. A very good feature, since at the time you make a change you can note immediately whether or not the change code remains Java compliant.

Using X-Designer for building Microsoft Windows applications is another prime feature. X-Designer must be started in Windows mode to enable this cross-platform development. It can be done via resource, or via running it by typing xdesigner<\!s>-windows. In this case, an additional button is added to the tool bar, to toggle the Windows compliance. The procedure is similar to the one used for Java. If you read an already created Motif design into Windows-aware X-Designer, it prompts you with a dialog containing all the warnings and reasons for Windows non-compliant design. Sometimes it can fix the problems, other times it cannot.

Code for Windows is always generated as C++, in three flavours: Motif, MFC or Motif XP. Motif XP is a set of provided classes similar to Motif, but named to match the Microsoft Foundation Classes. Since Motif is much more flexible and allows more freedom than MFC, the basic task X-Designer must perform is to apply additional constraints on the design to force Windows compliance. This is the only method of MFC code generation. In all the dialogs, a convention is used for the MFC-honoured resources; if the entry field or button is painted pink, it means that the resource is honoured only by Motif and not by MFC.

X-Designer contains very advanced tools for C++ class structure and hierarchy maintenance. A subset of a design can be created as a C++ class, and access control can be applied for any widget member. One can use methods such as callbacks and even create custom preludes into the source code to add additional class members. An interesting feature is definition creation, which can be put on the widget palette as a reusable group of widgets. C++ programmers will find the abundance of features extremely useful, as the class structure becomes the property of the design and can be maintained in cross-platform applications.

All the code-generation options are well beyond the scope of this review, but I am convinced that even though Motif is the native toolkit of X-Designer, Java and MFC support are advanced, and most importantly, they work. For any design information that can be ported to Java or MFC, X-Designer keeps track of it and properly implements it. Every issue is considered, including font inconsistencies, color incompatibilities, different native pixmap formats and problems with long filenames under Windows platforms.