Which GUI builder do you prefer? I have worked with several, and have a few opinions (feedback welcome!).

A GUI builder can be a great help, and speed up the creation of a user interface. You can try several layouts easily then choose the best. However, you will still need to understand X11, Xt, and Motif. Once the layout has been designed and it looks reasonably good, you can close up the GUI builder and edit its intermediate file in a text editor, to change resource values more quickly.

A GUI builder can also help with cross platform development, making it easier to support both Motif and MS-Windows. However, you run into the Least Common Denominator (LCD) problem. If you use only the subset of features which is common to all target platforms, then the result does not appear really slick on any platform.

If you want the result to be really slick and you have the time, then throw out the GUI builder and code to the Motif API. Dan Heller makes a good case for this in Volume 6A, Motif Programming Manual, O'Reilly. Make best use of the COSE CDE widgets.

X Designer (XD) is an excellent value when purchased with SparcWorks. Sun calls it "Visual" and ships it with minimal documentation, but it is easy to use. It generates 'c' or 'c++' code which is portable across all Unix platforms that I have used, so you don't need to pay extra for 'porting kits'. The internal files have a '.xd' extension, and can be edited if you are careful. See http://www.sun.com.

UIM/X may be slightly more powerful than XD, but you pay more. As with XD, 'porting kits' are not necessary. You don't need to use a Sun; UIM/X can be hosted on any vendor's workstation. The internal files have an '.i' extension and are easier to edit than for XD.

TeleUse is the most powerful GUI builder I ever used, but the price is steep. The dialog language simplifies the implementation of GUI interaction with your application code, but requires a 'porting kit' for each type of Unix. This dialog language also makes you dependent on TeleUse. The cross platform support includes MS-Windows (recent, untried).

Colour Allocation in a Motif App

How do you make best use of the 256 colours in a Pseudocolor X11 visual? A common technique is to allocate Read Only (shared) X11 colours for all the app's desired colours. The app loops through its list of desired colors, allocating each from the X11 default colormap. If the available colours are exhausted, then the allocated colours must be deallocated, and a private colormap is created to allow the use of all 256 colours.

It is a drastic step to use a private colormap, because this will cause "colour flashing" or "technicolor" as the pointer is moved between windows. This is visually disconcerting, so it is best avoided. A different technique, which works almost as well, is to make a best effort to allocate the colours but not guarantee that all colours will be exact. This can be surprisingly effective, with often no visible degradation. The user is given a menu option to get exact colours if desired, thus giving her a workaround if the "Best Effort" algorithm is not satisfactory.

Best Effort Algorithm

The Best Effort algorithm is as above, with the app's colours allocated Read Only from the Default colormap. The difference is that when there are no more available colours, then X11 is queried to get a table of the 256 colours which are currently in the Default colormap. Then the app's remaining colours are assigned to the closest values in this colormap. The closest value could be determined by summing the absolute differences of R G and B. A better approximation comes from using the HSV colour space, and taking into account gamma correction.

This algorithm can also be used with multiple images each in its own window. The window which is highest in the stacking order gets first priority in allocating colours. The other windows (which might be partially hidden) get a lower priority and appear with approximate colours.

This algorithm would seem to hog the Default colormap, shutting out all other applications. There is a solution: monitor the FocusIn and FocusOut events. When the focus is lost from a window, then the image colours must be deallocated in all windows of the application. When the focus enters a window, then the stacking order might have changed, so the Best Effort algorithm is used to reallocate the colours. Performance is not instantaneous, but it is quite good on modern workstations. Note that it will be faster when other applications have allocated more colours, because there are fewer round trips to the X11 server.

For the Best Effort algorithm to work well, the app's list of desired colours must be sorted in order of greatest importance to the image. John Bradley of XV fame has done the best work on this, and his Diversity algorithm is discussed in the manual that comes with XV, available from many network ftp servers. To summarize, the colour values used most frequently in the image are important. Also important are the colour values which are most different than the currently allocated colours, because they are needed for image detail.

We don't want to fall back on the colour cube algorithm, because it generally causes bands of colour to be apparent. This algorithm is only useful if several images must be displayed at once, because they are unlikely to share colour values. Then all of the images will look equally bad. A similar argument applies to colour dithering algorithms.

Private Colormaps with Motif

When a private colormap must be used, it causes a problem with Motif. The colours Motif uses for its widgets get lost so the widgets appear in false colours and can become almost unusable. Furthermore, the Motif colours can not be changed easily. One solution to this problem is to rearrange the private colormap so that the widgets will get reasonable colours.

At startup, when Motif has initialized its widgets, the app finds out which colour cells Motif is using for its colours (foreground, background, top shadow, bottom shadow, and maybe others). Then, before an image is displayed, it is scanned to find which of its colours have similar intensity to the Motif colours. The private colormap can then be rearranged, with the appropriate colours in the cells that Motif is using. This makes it possible to use all 256 colours for the image, but if fewer than 252 colors are needed then Motif can be given its exact colours.

Gamma Correction

Gamma Correction makes a big improvement in displaying an image. It has been described well in the documentation accompanying XV and Xearth, both available from network ftp servers. The intent is to correct for the nonlinear response of the CRT display and the light receptors in the retina. This correction must be adjustable by the user, because displays all have different response characteristics. Also, the user will want to turn off gamma correction for an imported image which has already been gamma corrected by its creator.