AppPlusShell Widget ----------
------------------------------------------------------------
From the Xt FAQ:
---------------------------------------------------------------------- 4.
How do I use a different visual than the default? ---------
-------------------------------------------------------------
This requires a more complicated answer than it should. A window has three
things that are visual specific -- the visual, colormap and border pixmap.
All widgets have their own Colormap and BorderPixmap resource; only shell
widgets have Visual resources (another questions deals with why shells have
a Visual). The default value of these resources is CopyFromParent which
does exactly what it says. In the shell widget CopyFromParent gets
evalulated as DefaultVisualOfScreen and DefaultColormapOfScreen. When any
one of the three resources is not properly set, a BadMatch error occurs
when the window is created. They are not properly set because each of the
values depends on the visual being used.
How to get this to work? There are two parts to the answer. The first is
if you want an application to start with a particular visual and the second
is if you want a particular shell within an application to start with a
different visual. The second is actually easier because the basic
information you need is available. The first is a little harder because
you'll need to initialize much of the toolkit yourself in order to
determine the needed information.
----------------------------------------------------------------------
This doesn't seem like the correct solution to me. First, its not
reusable, and second it's not user configurable thru resources. This was
the inspiration behind the AppPlusShell widget.
The AppPlusShell adds the following to the application shell:
1) Visual/Colormap control thru resources 2) EditRes built in (can be
turned on/off) 3) Catches the WM_DELETE_WINDOW
It does this thru the following added resources:
For 1: XtNvisualClass XtNusePrivateColormap XtNvisualID XtNapplicationDepth
For 2: XtNallowEditRes
For 3: XtNsaveYourselfCallback
The algorithm is as follows, in this order:
1) if XtNvisualID is set try to use the visual with this id, if it exists.
2) if XtNapplicationDepth is set try to find a visual with that depth,
otherwise set it to DefaultDepth(). This allows users to have:
*applicationDepth: 24
which will be used if it exists. XtNapplicationDepth is needed instead of
XtNdepth, since, IMO, most users will want to do
*depth: 24
which would screw up for any subwidgets if there were no visual with a
depth of 24. Note that the depth gets correctly set in the initialize too.
3) if XtNvisualClass is set then find the visual with the that class and
the greatest depth.
4) if all else fails use the default visual/default depth.
5a) if he visualID == default visual id, and XtNusePrivateColormap is
FALSE, then use the default colormap, otherwise, create an appropriate one.
5b) If the XCC library is in use, it would call the XCC lib at this point
instead.
Plus, there is now a file called SubPlusS.c that containts
functions for creating popup/menu shells with the correct
visuals/colormaps/depths.
The only other thing of interest is if you define MOTIF the code
uses some Motif functions instead of their X/Xt equivalents, but otherwise
should work with pretty much any Xt widget set.
I use a version of this code in our product, and so it has been
used on just about every major U*x platform with success.
Let me know what you think...(Otherwise I'll stop writing this
stuff...Well, after I finish this next one, then that's it..., Yeah, that's
it...)
John L. Cwikla cwikla@wri.com
