X-Designer

X-Designer is a state-of-the-art, multiple-award-winning GUI builder that runs on most Unix/X workstations. It generates native code for the OSF/Motif widget set, with sources either in C, C++ or UIL, the Motif user interface language. Not just for Motif, it can also produce code which compiles on Microsoft Windows platforms, using the MFC class library for GUI elements. Sounds promising, doesn't it? The very edition I had in my hand read X-Designer release 4.6: Java Edition--it can produce Java code as well.

Naturally, my excitement was growing as I opened the stylish box and got ready to install this expensive piece of software on my PC. Inside the box, I found a small manual called “Installation and Release Notes”, a large book of 840 pages with the title “Release 4.6 User Guide”, some advertisements and licensing material, two reference cards and a white CD-ROM containing the software.

The target PC was a 100MHz Pentium with 16MB RAM and 16 bpp XFree3.2 server for the ATI Mach64 graphics adapter with 2MB memory. This was more than enough memory for X-Designer. The Linux residing on the PC disks was a Slackware 3.0 distribution with 2.0.0 kernel. I had no Motif, just freely available lesstif libraries version 0.81. After all, X-Designer manuals claimed that Motif is not needed for running the builder and only Motif version 1.2 is needed for the created applications, not the newer 2.0 version.

Installation was smooth and trouble-free. As soon as the CD-ROM is mounted, X-Designer can be run in demo mode if the ISO 9660 Rock Ridge extensions are supported. The installation is done with a single Install command, where the only mandatory specifications are the location of the LINUX distribution files (e.g., /cdrom/LINUX) and the destination directory (/usr/local/xdesigner/ in my case). The installation took about 21MB of disk space and was accomplished in a robust and straightforward way. No fancy installation options, but you can rely on its successful completion.

Immediately after installation, the X-Designer still ran only in demo mode, which doesn't enable saving the designs or generating any code. I proceeded to the licensing section of the installation manual. To obtain the license, a special host ID must be calculated with a provided program and e-mailed to IST for the license request. The support staff responded within minutes. Using the very good manual section about setting up the license file and running the provided IST licensing daemon, I had X-Designer up and running under full power less than 30 minutes from the time I started the installation.

Figure 1. Main Window

The user interface is appealing and is designed with programmers in mind, not the users who go “aaaah” at every flashy icon that pops up. Help was there, as it should be with any Motif application. By default, the provided XD/Help browser is launched at help request, but there is an option to use Netscape or any other browser for the same purpose. I prefer the provided XD/Help utility, since Netscape offers the same functionality but eats up system resources mercilessly compared to the small XD/Help and even X-Designer itself. Help is all in text mode, but I believe that after using X-Designer for some time, the need for the on-line help slowly vanishes. There is no Motif programming information provided, and the widgets are described only briefly. A Motif reference book should be handy while seriously using X-Designer. I believe the help system serves its purpose very well and is designed with the correct assumption that advanced users do not need a lot of colorful diagrams, examples and tips, but just a quick reminder of what is happening.

2641f2.gif

Figure 2. Help Utility

The work area of the main window provides a fair display of the widget instance tree structure. As the widget trees can grow large for larger applications, many options are provided to keep much of the design within visual range. Branches can be collapsed, and the icons for the widgets can be set to a smaller size. The tree can be left-justified and the special annotation bitmaps can be placed beside widgets to visually remind the user of their special properties. The work area has a highly professional design and provides the developer with the needed information about the designed GUI.

The application appearance is built simultaneously as the elements are added to the design tree. X-Designer doesn't simulate the appearance; it actually builds the widget tree from the real widgets. This makes it a sort of WYSIWYG GUI builder, which introduces a dangerous possibility. If the actual widgets created while building the application are connected or configured in a forbidden manner, X-Designer may crash because an unexpected widget condition will appear within the X-Designer executable. Being aware of this problem, I tried to create all kinds of weird designs, but X-Designer is very strict and positively sure it knows more about Motif than I do—it would not allow me to add invalid widget relations to my design.

Figure 3. Typical Resource Box

All the standard editing options are present, including support for printing a PostScript image of your widget trees. The resource boxes are available, as one would expect from a GUI builder. A separate resource panel and core resource panel are available for each widget. The panels are aware of the Motif defaults and let you set any resource. The Motif power is not hidden in any way; it is just easier to use.

Callbacks can be manipulated in a similar way. The dialogs for setting callbacks allow you to type in the name of the function and the client data which is to be passed to the callback along with the other parameters. X-Designer does not implement an editor for directly editing the code, but there is an “Edit” button in the callback dialog. It runs your favourite editor as defined by the EDITOR environment variable. As I am an Emacs fan, I use emacsclient as my editor, which connects to the running Emacs server for file editing. At first I was annoyed to find the extra xterm popping up to run emacsclient. However, the User's Guide is very informative, and with its help I quickly found the location of the shell script which X-Designer uses to run the editor. I added the emacsclient, and no more annoying xterm. The configurability of X-Designer is worth all the money you pay for it.

Editing the callbacks actually means editing the stubs file, which is generated during the code-generation process. X-Designer puts a short comment before each callback, which must be left intact if you want to keep your callback code after generating successive stubs files. You can even add some code into the stubs file which has nothing to do with the callbacks, and it will be left there after regeneration of the source files. Just follow the well-documented method by which X-Designer treats those comments.

Besides the usual callbacks, links can be created as well. They are special simple callbacks which can be attached to buttons in order to trigger simple actions like enable/disable, manage/unmanage or show/hide certain widgets. Basically, links are just callbacks which are saved with your design into an .xd file and actually work in the prototype GUI built dynamically by X-Designer. Note that the regular callback code is not saved anywhere other than in the stubs file.