Unsafe use of default visual, depth, screen, colormap

[DaveFlater]

An application can provide a non-default visual to XtAppCreateShell and XtCreatePopupShell. That visual is then inherited by all the contained widgets that unconditionally use CopyFromParent. Only Shell actually has a visual resource.

To avoid a Bad Match or related error, all the operations that need a visual or an attribute of a visual (e.g., the color depth) have to remain compatible with the visual that the Shell has.

ThreeD, SmeThreeD, and Tip all use DefaultDepth and assume that this is the depth of the visual in use. The function Xaw3dXftDrawString uses both DefaultDepth and DefaultVisual and assumes them to be compatible.

Xaw3dXft.c uses DefaultScreen a lot instead of XtScreen(widget) or the screen resource.

Notably, none of these points are in code that was inherited from Xaw; all are in code that was added in Xaw3d or Xaw3dXft.

[DaveFlater]

ThreeD and SmeThreeD: BlackPixelOfScreen, WhitePixelOfScreen, and grayPixel (defined in Xaw3dP.c) all refer to the default colormap of the screen.

An application needing to use a non-default visual has to constantly override visual, depth, colormap, and any or all of foreground, background, borderColor, background_pixel, border_pixel, etc. Xt: "XtDefaultForeground and XtDefaultBackground evaluate to the black and white pixel values of the widget's screen" Xlib: "BlackPixel and WhitePixel... are for permanently allocated entries in the default colormap."

This is an ancestral curse. The scope of work for Xaw3dXft is making sure that we use the non-default stuff that was provided by the application and not flip back to the defaults and cause a Bad Match error.

In the previous century I had to use an Openwin setup where the default was 8-bit PseudoColor but the application could get 24-bit True Color by asking for it. Whether I can replicate that in current year is TBD.