Archive-name: motif-faq/part3
Last-modified: 1 FEB 2002
Posting-Frequency: irregular
Organization: Kenton Lee, X/Motif Consultant, http://www.rahul.net/kenton/
URL: http://www.rahul.net/kenton/mfaq.html
Version: 8.1



-----------------------------------------------------------------------------
Subject: 40) How does Motif work with X11R5?

Answer: Motif 1.1.X is only intended to be built with X11R4. Motif 1.2.X is
for X11R5. however, Motif 1.1.4 has been set to also work with X11R5.

For Motif 1.1.1, 1.1.2 and 1.1.3 you will need to compile Xlib and Xt with a
MOTIFBC flag set to YES (page 8, section 3.3 of the R5 release notes), or
you'll also have a link problem (LowerCase) and a fatal run time problem
(XContext manager). If your applications come up with "Unknown keysym name:
osfActivate" errors, check the variable ProjectRoot. The name
/$PROJECTROOT/lib/XKeysymDB will have been wired into your Xlib.

In Motif 1.1.0, XtCallCallback uses NULL as the first argument instead of a
widget ID. This was ok under R4, but must be changed in the source for R5. It
was changed by OSF from Motif 1.1.1 onward.

Mrm won't work at all (can't link since it uses an X private variable that has
disappeared in R5). There is an MIT patch that may fix this??

-----------------------------------------------------------------------------
Subject: 41) Where can I find X technical info on the WWW?
[Last modified: Mar 96]

Answer:

Technical X Window System and OSF/Motif WWW sites
http://www.rahul.net/kenton/xsites.html

This web site currently lists over 700 X Window System links, including
technical papers, tutorials, FAQs, product reviews, etc.

-----------------------------------------------------------------------------
Subject: 42) What is Broadway? I've heard it called "X on the Web".
[Last modified: Jun 98]

Answer: Broadway was the X Consortium's internal code name for the X11R6.3
release. It includes a collection of X-based technologies for the World Wide
Web. For details, see:

http://www.camb.opengroup.org/tech/d...x/broadway.htm

And if you're wondering. "Why did they call it Broadway?", the X Consortium
was located at 201 Broadway, Cambridge, MA.... ksall@cen.com

-----------------------------------------------------------------------------
Subject: 43) Where's an HTML version of the Motif FAQ on World Wide Web
(WWW)?
[Last modified: Feb 95]

Answer: An automatically generated HTML version of this Motif FAQ can be found
at WWW URL:

http://www.cis.ohio-state.edu/hypert...f-faq/top.html

For a searchable version of the Motif FAQ and other FAQs (via WAIS), see:

http://www.cs.ruu.nl/cgi-bin/faqwais

The WAIS search is great way to find a topic which may appear in several FAQs
(Motif, X, Xt, Widget FAQ, etc.)

-----------------------------------------------------------------------------
Subject: 44) Where can I get the HTML widget used in Mosaic?
[Last modified: Mar 96]

Answer: Thanks to Matthew Freedman (mattf@cac.washington.edu) and
intasoft@cix.compulink.co.u for updates to the URLs mentioned in this answer.

Ken Sall (ksall@cen.com) writes: The HTML (HyperText Markup Language) widget
is part of the NCSA Mosaic source code available from ftp.ncsa.uiuc.edu. Look
in the "libhtmlw" subdirectory of the "Mosaic-src-*" subdirectory of:

ftp://ftp.ncsa.uiuc.edu/Mosaic/Unix/source/

or, more generally, look for the files HTML.c, HTML.h, HTMLP.h, etc. in your
"libhtmlw" subdirectory of the Mosaic source.

For (old) documentation, see

http://www.ncsa.uiuc.edu/SDG/Softwar...tmlwidget.html.

However, Matthew M. Freedman (mattf@cac.washington.edu) pointed out the
document is out of date: "One important thing to know is that the on-line
documentation for the Mosaic html widget is out of synch with the source code.
I e-mailed NCSA about this in May, but they seem to have ignored the report.
The one that I wasted half a day because of is HTMLSetText(). The on-line docs
list four arguments, but in fact there are seven. I have no idea what the
extra three undocumented parameters are used for, I just plugged in NULL's and
it works. The other error I noticed is that they document a "page" field in
WbAnchorCallbackData, but it does not actually exist. Also, at least for me,
after I call HTMLSetText() the first time, the widget remains blank. I have to
lower and raise the window for it to be drawn. Anybody know what is wrong? I
guess will probably just spoof an expose in my code."


For information on using Mosaic by remote control, see

http://www.ncsa.uiuc.edu/SDG/Softwar.../cci-spec.html
and
http://www.ncsa.uiuc.edu/SDG/Softwar...e-control.html


Here are more details from ah627@FreeNet.Carleton.CA (Samuel Effah):

To the numerous request for the NCSA HTML widget information.

Everything not already copyrighted by CERN is copyrighted by NCSA (including
the contents of the libhtmlw, libnet, libXmx, and src directories, but not
including the contents of libdtm, which is entirely public domain). ...

* The UI grants you (hereafter, Licensee) a license to use the Software *
* for academic, research and internal business purposes only, without a *
* fee. Licensee may distribute the binary and source code (if released) *
* to third parties provided that the copyright notice and this statement *
* appears on all copies and that no charge is associated with such *
* copies. *
* *
( you can read more about the copyright in the Mosaic source code ).


Documentation on the HTML widget can be located at:

http://www.ncsa.uiuc.edu/SDG/Softwar...tmlwidget.html
( it's on the older version, I think Mosaic1.x )

For starters, you can compile directory Mosaic2.4/libhtmlw for the widget.
Using: To create widget:
htlmWid = XtCreateManagedWidget( "htlmWid",
htmlWidgetClass, parent,
htlmArgs,
XtNumber( htlmArgs ));

Callback for anchors:
XtAddCallback(htlmWid, WbNanchorCallback, htmlRef, NULL);

where htmlRef() looks like:

static void htmlRef(widget, client_data, call_data) Widget widget; XtPointer
client_data; WbAnchorCallbackData* call_data; {
buffer = readHTMLFile( call_data->href );
XtVaSetValues( widget, WbNtext, buffer, NULL ); }

where readHTMLFile() is

char * readHTMLFile( in_file ) char *in_flie; {
/* function to read a file and return its content, given
the file's name */ }

I think this is enough to start you off.


Thanks to: Samuel Effah

-----------------------------------------------------------------------------
Subject: 45)* What widgets does Netscape use for its bookmarks list and
preference panels?
[Last modified: Jan 02]

Answer: Netscape uses the Microline widget set. Microline was purchased by
Neuron Data (http://www.neurondata.com/), but they no longer sell the
Microline widget set.

Some of the Microline widgets are available in the Mozilla source code:
http://lxr.mozilla.org/classic/sourc.../Microline3.0/

Ken Lee, http://www.rahul.net/kenton/

-----------------------------------------------------------------------------
Subject: 46) TOPIC: BOOKS and JOURNALS

-----------------------------------------------------------------------------
Subject: 47) Is there a Motif tutorial? Xt tutorial? X11 tutorial?
[Last modified: Nov 96]

Answer: For the most up-to-date links to Motif/X11/Xt tutorials, see:

http://www.rahul.net/kenton/xsites.html#Xtutorials
On-line X programming tutorials (Kenton Lee's multi-lingual links)


See http://www.cm.cf.ac.uk/Dave/X_lecture/X_lecture.html
for a hypertext Motif tutorial (by David Marshall) with source code and
illustrations.

Marshall Brain at brain@adm.csc.ncsu.edu posted a set of simple and useful
Motif tutorials at http://www.iftech.com/ .

Jan Borchers writes about his Xmtutor:

"Xmtutor" is an interactive tutorial teaching you how to write Motif
applications. While it comes with a complete printable book file, its key
component is the online version of the tutorial: It's a Motif application
itself, and its examples are actual running Motif applications. You can modify
their resource settings from within the tutorial, and then play with them to
see how their interface reacts. For the free version, screen shots,
registration, and more information check out the Xmtutor home page at:

http://www.stanford.edu/~borchers/xmtutor/


More on-line Motif tutorials and technical papers are listed on my web site:

http://www.rahul.net/kenton/


-----------------------------------------------------------------------------
Subject: 48) What books are available for Motif application programmers?
[Last modified: Mar 98]

Answer: NOTE: This subject is impossible to keep meaningfully up to date and
has been deleted.

-----------------------------------------------------------------------------
Subject: 49) What relevant journals are available?
[Last modified: Jun 98]

Answer: In October, 1997, ICS has launched The Motif Zone at

http://www.motifzone.com/

This web site contains a Motif reference section and an on-line magazine
called *The Motif Developer*.

Several other Motif-oriented magazines have existed in the past, but are
ceased publishing. Their back issues are still very interesting, though.
Back issues of the print magazines may be available from their publishers or
at better technical libraries. Back issues of "The X Advisor" are no longer
on line.

"The X Journal" was published bimonthly by SIGS Publications, +1-212-274-0640.
"The X Resource: A Practical Journal of the X Window System" was published
quarterly by O'Reilly and Associates, +1-800-998-9938.

-----------------------------------------------------------------------------
Subject: 50) TOPIC: MWM and the SHELL WIDGET

-----------------------------------------------------------------------------
Subject: 51) What is the difference between Motif and mwm?

Answer: mwm is a window manager.

Motif itself is made up of four parts: a User Interface Style Guide, an API
toolkit of `C' routines which helps in the building of applications which
conform to the style guide, the window manager mwm, and a language UIL which
is designed to ease user interface development.

In general mwm will run any application built with any X Window System API,
and in general an application built using the Motif toolkit will run under any
window manager.

-----------------------------------------------------------------------------
Subject: 52) Does anyone have an alternative set of 3-D defaults for a
monochrome screen?

Answer: This is obviously a matter of taste. Some alternatives suggested
include

!Benjamin Schreiber, bs@osf.osf.org, bs@cs.brandeis.edu
Mwm*foreground: black ! Actually, when a window is
Mwm*background: white ! deactivated, the background
Mwm*backgroundPixmap: 50_foreground ! becomes white, insted of
Mwm*topShadowPixmap: white ! 50% foreground (grey)

Mwm*activeForeground: black
Mwm*activeBackground: white
Mwm*activeBackgroundPixmap: 50_foreground
Mwm*activeTopShadowPixmap: white

Mwm*menu*backgroundPixmap: background
Mwm*menu*topShadowPixmap: 50_foreground

Mwm*title*foreground: black
Mwm*title*background: white
Mwm*title*backgroundPixmap: white
Mwm*title*topShadowPixmap: 50_foreground
Mwm*title*activeForeground: white
Mwm*title*activeBackground: black
Mwm*title*activeBackgroundPixmap: black
Mwm*title*activeBottomShadowPixmap: 50_foreground

Mwm*feedback*backgroundPixmap: white

or

! From: tsang@isi.com (Kam C. Tsang)
Mwm*background: White
Mwm*activeBackground: White
Mwm*activeBackgroundPixmap: 25_foreground
Mwm*foreground: Black
Mwm*activeForeground: Black
Mwm*menu*background: white
Mwm*menu*foreground: black
xterm*Foreground: black
xterm*Background: white

or

! From: ucsd.edu!usc!snorkelwacker!paperboy!yee (Michael K. Yee)
Mwm*cleanText: True

Mwm*activeBackground: white
Mwm*activeForeground: black
Mwm*background: white
Mwm*foreground: black

Mwm*client*activeBackgroundPixmap: 50_foreground
Mwm*client*activeTopShadowPixmap: foreground
Mwm*client*activeBottomShadowPixmap: background

!Mwm*client*background: white
!Mwm*client*foreground: black
Mwm*client*backgroundPixmap: 75_foreground
Mwm*client*topShadowPixmap: foreground
Mwm*client*bottomShadowPixmap: background

!Mwm*feedback*background: white
!Mwm*feedback*foreground: black
Mwm*feedback*backgroundPixmap: 50_foreground
!Mwm*feedback*topShadowPixmap: 25_foreground
!Mwm*feedback*bottomShadowPixmap: background

!Mwm*menu*background: white
!Mwm*menu*foreground: black
Mwm*menu*backgroundPixmap: foreground
!Mwm*menu*topShadowPixmap: foreground
!Mwm*menu*bottomShadowPixmap: background

!Mwm*icon*background: white
!Mwm*icon*foreground: black
Mwm*icon*activeBackgroundPixmap: 50_foreground
Mwm*icon*activeBottomShadowPixmap: foreground
Mwm*icon*backgroundPixmap: 75_foreground


-----------------------------------------------------------------------------
Subject: 53) What are some useful mwm resources I can control?
[Last modified: Sept 95]

Answer: Ken Sall (ksall@cen.com) writes: The following are described in the
mwm(1) man page:

clientAutoPlace (class ClientAutoPlace)
focusAutoRaise (class FocusAutoRaise)
interactivePlacement (class InteractivePlacement)
positionIsFrame (class PositionIsFrame)
positionOnScreen (class PositionOnScreen)
useIconBox (class UseIconBox)


-----------------------------------------------------------------------------
Subject: 54) How can I configure mwm, such as changing or adding to root
menus?
[Last modified: Oct 95]

Answer: Read the mwm(1) man page which describes how to configure mwm using
the .mwmrc file. The default location of the system-wide version of this file
is /usr/lib/X11/system.mwmrc. You can override settings in the global file by
creating your own $HOME/.mwmrc.

-----------------------------------------------------------------------------
Subject: 55) How can my program determine which window manager is running?
[Last modified: Nov 97]

Answer: Each window manager has its own signature, but unfortunately there is
no standard query mechanism. Motif provides XmIsMotifWMRunning() to test for
mwm.

-----------------------------------------------------------------------------

Subject: 56) How can I modify the mwm's window decorations with a resource
file?
[Last modified: Dec 97]

Answer: Set mwm's client resource "clientDecoration" for your particular
application. For example,

Mwm*XClock.clientDecoration: none

turns off all clock decorations. See the mwm man page for other options and
other mwm client resources.

-----------------------------------------------------------------------------

Subject: 57) How can I programatically modify the mwm's window decorations?
[Last modified: July 95]

Answer: Programmatically, set the VendorShell resource XmNmwmDecorations to 0,
such as:

#include /* see MWM_DECOR_* and MWM_FUNC_* */
#include
popupShell =
XtVaCreatePopupShell( "PopupShell",
xmDialogShellWidgetClass, toplevel,
XmNmwmDecorations, 0,
NULL );

With the 0, you have no decorations at all, but if you want just a little
frame, use MWM_DECOR_BORDER instead.

Thanks to Guillaume.Gallais@asm.thomson.fr for the code fragment and pointing
out that there is no MWM_DECOR_NONE.

Reinhard M. Weiss (weissrm@execpc.com) also pointed out that MWM_DECOR_NONE
was fictitious. He also added:

"I have found that the resource XtNoverrideRedirect does cause the olwm to
remove all decorations (my guess is that it would work in mwm roughly the
same). This works programmatically as well as in resource files (i.e.
*.className*overrideRedirect: true). There are some undesirable effects to
this, however, particularly with focus and managing dialogs and popups."

-----------------------------------------------------------------------------
Subject: 58) Is there an ICCCM compliant way of setting window manager
decorations?

Answer: Tom LaStrange (toml@LaStrange.COM) writes: "No, there is no ICCCM
portable way to alter decorations."

-----------------------------------------------------------------------------
Subject: 59) How can I put decorations on transient windows using olwm?

Answer: This code is from Jean-Philippe Martin-Flatin :

/************************************************** ********************
** WindowDecorations.c
**
** Manages window decorations under the OpenLook window manager (OLWM).
**
** Adapted from a C++ program posted to comp.windows.x.motif by:
**
** +--------------------------------------------------------------+
** | Ron Edmark User Interface Group |
** | Tel: (408) 980-1500 x282 Integrated Systems, Inc. |
** | Internet: edmark@isi.com 3260 Jay St. |
** | Voice mail: (408) 980-1590 x282 Santa Clara, CA 95054 |
** +--------------------------------------------------------------+
************************************************** *********************/

#include
#include
#include
#include
#include
#include
#include
#include

/*
** Decorations for OpenLook:
** The caller can OR different mask options to change the frame decoration.
*/
#define OLWM_Header (long)(1<<0)
#define OLWM_Resize (long)(1<<1)
#define OLWM_Close (long)(1<<2)

/*
** Prototypes
*/
static void InstallOLWMAtoms (Widget w);
static void AddOLWMDialogFrame(Widget widget, long decorationMask);


/*
** Global variables
*/
static Atom AtomWinAttr;
static Atom AtomWTOther;
static Atom AtomDecor;
static Atom AtomResize;
static Atom AtomHeader;
static Atom AtomClose;
static int not_installed_yet = TRUE;


static void InstallOLWMAtoms(Widget w)
{
AtomWinAttr = XInternAtom(XtDisplay(w), "_OL_WIN_ATTR" , FALSE);
AtomWTOther = XInternAtom(XtDisplay(w), "_OL_WT_OTHER", FALSE);
AtomDecor = XInternAtom(XtDisplay(w), "_OL_DECOR_ADD", FALSE);
AtomResize = XInternAtom(XtDisplay(w), "_OL_DECOR_RESIZE", FALSE);
AtomHeader = XInternAtom(XtDisplay(w), "_OL_DECOR_HEADER", FALSE);
AtomClose = XInternAtom(XtDisplay(w), "_OL_DECOR_CLOSE", FALSE);

not_installed_yet = FALSE;
}

static void AddOLWMDialogFrame(Widget widget, long decorationMask)
{
Atom winAttrs[2];
Atom winDecor[3];
Widget shell = widget;
Window win;
int numberOfDecorations = 0;

/*
** Make sure atoms for OpenLook are installed only once
*/
if (not_installed_yet) InstallOLWMAtoms(widget);

while (!XtIsShell(shell)) shell = XtParent(shell);

win = XtWindow(shell);

/*
** Tell Open Look that our window is not one of the standard OLWM window
** types. See OLIT Widget Set Programmer's Guide pp.70-73.
*/

winAttrs[0] = AtomWTOther;

XChangeProperty(XtDisplay(shell),
win,
AtomWinAttr,
XA_ATOM,
32,
PropModeReplace,
(unsigned char*)winAttrs,
1);

/*
** Tell Open Look to add some decorations to our window
*/
numberOfDecorations = 0;
if (decorationMask & OLWM_Header)
winDecor[numberOfDecorations++] = AtomHeader;
if (decorationMask & OLWM_Resize)
winDecor[numberOfDecorations++] = AtomResize;
if (decorationMask & OLWM_Close)
{
winDecor[numberOfDecorations++] = AtomClose;

/*
** If the close button is specified, the header must be
** specified. If the header bit is not set, set it.
*/
if (!(decorationMask & OLWM_Header))
winDecor[numberOfDecorations++] = AtomHeader;
}

XChangeProperty(XtDisplay(shell),
win,
AtomDecor,
XA_ATOM,
32,
PropModeReplace,
(unsigned char*)winDecor,
numberOfDecorations);
}


/*
** Example of use of AddOLWMDialogFrame, with a bit of extra stuff
*/
void register_dialog_to_WM(Widget shell, XtCallbackProc Cbk_func)
{
Atom atom;

/*
** Alias the "Close" item in system menu attached to dialog shell
** to the activate callback of "Exit" in the menubar
*/
if (Cbk_func)
{
atom = XmInternAtom(XtDisplay(shell),"WM_DELETE_WINDOW",TRUE);
XmAddWMProtocolCallback(shell,atom, Cbk_func,NULL);
}

/*
** If Motif is the window manager, skip OpenLook specific stuff
*/
if (XmIsMotifWMRunning(shell)) return;

/*
** Register dialog shell to OpenLook.
**
** WARNING: on some systems, adding the "Close" button allows the title
** to be properly centered in the title bar. On others, activating
** "Close" crashes OpenLook. The reason is not clear yet, but it seems
** the first case occurs with OpenWindows 2 while the second occurs with
** Openwindows 3. Thus, comment out one of the two following lines as
** suitable for your site, and send e-mail to syj@ecmwf.int if you
** find out what is going on !
*/
AddOLWMDialogFrame(shell,(OLWM_Header | OLWM_Resize));
/* AddOLWMDialogFrame(shell,(OLWM_Header | OLWM_Resize | OLWM_Close)); */
}


-----------------------------------------------------------------------------
Subject: 60) How can I turn off the Motif window manager functions from the
system menu?
[Last modified: October 92]

Answer: The user of an application can control functions in the system menu
for an application using the mwm resource clientFunctions:

mwm.application_name.clientFunctions: -resize -close

Note that mwm will have to be restarted after putting this in their resource
database.


Answer: The writer of an application can only remove items. Be warned that
your users will probably gnash their teeth, swear furiously at your product
and stop using it if they discover that you have done this. (Especially if
you have removed the Close button, your application has hung and it has taken
up all of memory and swap so it can't be killed.) Much better is to catch the
action gracefully as in the next question.

#include

XtVaGetValues(shell, XmNmwmFunctions, &int_val, NULL);
int_val &= ~(MWM_FUNC_CLOSE | MWM_FUNC_ALL);
XtVaSetValues(shell, XmNmwmFunctions, int_val, NULL);


-----------------------------------------------------------------------------
Subject: 61) How can I create a multi-colored window manager icon?
[Last modified: Oct 95]

Answer: The only portable way to do this is with icon windows. The WMShell
widget supports icon windows with its XmNiconWindow resource. Set this to a
window that your application has created. The window could be the XtWindow()
of a realized shell widget. The window must be created with the default
visual and colormap of its screen. Other requirements on icon windows are
specified in section 4.1.9 of the X11R6 ICCCM. Note that some window managers
provide alternate techniques for creating color icons; none of these are
standard or portable.

Ken Lee

-----------------------------------------------------------------------------
Subject: 62) How can I keep my shell windows fixed in size?
[Last modified: Apr 95]

Answer: In addition to the decoration controls mentioned in the previous few
subjects of this FAQ, you can also specify size hints for your shell widget's
windows with these resources: XmNminWidth, XmNmaxWidth, XmNminHeight,
XmNmaxHeight. If you set the min and max values to the same size, most window
managers will not allow the user to resize the window.

Ken Lee

-----------------------------------------------------------------------------
Subject: 63) Why is XtGetValues of XmNx and XmNy of my toplevel shell wrong?
[Last modified: Oct 95]

Answer: [Note: This answer is borrowed from the Xt FAQ,
ftp://ftp.x.org/contrib/faqs/FAQ-Xt, devoted to X Toolkit Intrinsics.]

XmNx and XmNy are the coordinates relative to your shell's parent window,
which is usually a window manager's frame window. To translate to the root
coordinate space, use XtTranslateCoords().

-----------------------------------------------------------------------------
Subject: 64) How do I get XmNx and XmNy positions to be honored correctly?
[Last modified: Nov 96]

Answer: One answer is to pass the right hints to the window manager, perhaps
using XSetWMNormalHints. Another approach comes from Shane Burgess
(shane@radionics.com) who writes:

By setting the XmNdefaultPosition resource (on XmBulletinBoard or its
subclasses, including the message dialogs) to False, I've found that all my
XmNx & XmNy requests gets set correctly.

Pete Sakalaukus (sakalauk@pelican.st.usm.edu) says that XmNdefaultPosition
only works with olwm, not mwm.

-----------------------------------------------------------------------------
Subject: 65) How can my application know when the user has quit Mwm?
[Last modified: Feb 95]

Answer: Looking for an answer to this one. ANY TAKERS? (Still looking.)

-----------------------------------------------------------------------------
Subject: 66) How can I tell if the user has selected "Close" from the system
menu? How do I catch the "Close"? I need to do some clean up before exiting.
[Last modified: Aug 95]

Answer: Catching the mwm Close involves using XmAddWMProtocolCallback and
possibly setting the XmNdeleteResponse resource. Note that whether your
application involves multiple applicationShells vs. a single applicationShell
and multiple toplevelShells is significant. Following the two older code
fragments is a complete test application which can be compiled with different
#defines to alter the behavior.

This works with R4 Intrinsics

#include

void FinalCleanupCB(w, client_data, call_data)
Widget w;
caddr_t client_data, call_data;
{
/* tidy up stuff here */
...
/* exit if you want to */
exit (0);
}

main()
{
Atom wm_delete_window;

...
XtRealizeWidget(toplevel);
...
wm_delete_window =
XmInternAtom(XtDisplay(toplevel),
"WM_DELETE_WINDOW", False);
XmAddWMProtocolCallback(toplevel, wm_delete_window,
FinalCleanupCB, NULL);
XtMainLoop();
}

This will still kill the application. To turn this behaviour off so that the
application is not killed, set the shell resource XmNdeleteResponse to
XmDO_NOTHING. This means that users cannot kill your application via the
system menu, and may be a bad thing.

If you are running R3, Bob Hays (bobhays@spss.com) has suggested this:
"Trapping on the delete window atom does not work as I cannot force my action
routine to the top of the action list for the activity desired, so the window
manager kills my window anyway BEFORE I can do anything about it. And, to
make matters worse, the window manager (Motif in this case) tacks its atoms
and handlers onto the window at some unknown point down the line after the
creation of the shell widget as far as I can tell. So....

I have a procedure as an action routine for ClientMessage. Then, if I get a
property change event on the window manager protocols, I then tack on
WM_SAVE_YOURSELF. If I get this request, I clean up (it seems to happen on
WM_DELETE_WINDOW, BTW, if you remove WM_DELETE_WINDOW from the WM protocols
atom) and exit. Works great and is less filling overall:-)."

The following similar code fragment is from Dave Mink
(mink@cadcam.pms.ford.com):

void setupCloseCallback(Widget shell, XtCallbackProc closeProc)
{
/* get window manager delete protocol atom */
Atom deletewin_protocol = XmInternAtom(
XtDisplay(shell), "WM_DELETE_WINDOW", True
);
/* turn off default delete response */
XtVaSetValues( shell,
XmNdeleteResponse, XmDO_NOTHING,
NULL);
/* add callback for window manager delete protocol */
XmAddWMProtocolCallback(shell, deletewin_protocol, closeProc, NULL);
}


Here is a complete code example which can be compiled several different ways,
as per the comments in the code.


/*
* MWM Close test program.
*
* Creates 4 shells, testing each of 3 different values of XmNdeleteResponse.
* Compile will -DMULTIPLE_APP_SHELLS to make all 4 shells of type
* applicationShellWidgetClass. Otherwise, first shell created is
* applicationShellWidgetClass, but other 3 are topLevelShellWidgetClass.
* Results differ. You can also experiment with #defining POPUP_SHELL,
* BEFORE_CREATE, or AFTER_CREATE.
*
* Ken Sall (ksall@cen.com)
*/

#include

#include
#include

#include
#include
#include

#include /* for popup */
#include

#include
#include
#include

void CloseCB();
void popup_handler();

#ifdef MULTIPLE_APP_SHELLS
#define P1_TITLE "P1: applicationShell: XmDO_NOTHING"
#define P2_TITLE "P2: applicationShell: XmDESTROY"
#define P3_TITLE "P3: applicationShell: XmUNMAP"
#define P4_TITLE "P4: applicationShell: default"
#else
#define P1_TITLE "P1: applicationShell: XmDO_NOTHING"
#define P2_TITLE "P2: topLevelShell: XmDESTROY"
#define P3_TITLE "P3: topLevelShell: XmUNMAP"
#define P4_TITLE "P4: topLevelShell: XmDO_NOTHING"
#endif

void CloseCB (w, client_data, call_data)
Widget w; /* widget id */
caddr_t client_data; /* data from application */
caddr_t call_data; /* data from widget class */
{
XmAnyCallbackStruct *cb = (XmAnyCallbackStruct *) call_data;

printf ("caught Close from: %s\n", (char *)client_data );
if (strcmp ( P1_TITLE, (char *)client_data ) == 0 )
{
/* do something */
}
else if (strcmp ( P2_TITLE, (char *)client_data ) == 0 )
{
/* do something else */
}
else if (strcmp ( P3_TITLE, (char *)client_data ) == 0 )
{
/* do something else */
}
else if (strcmp ( P4_TITLE, (char *)client_data ) == 0 )
{
/* do something else */
}
else /* unreachable */
{
printf ("oops\n");
}
}

void popup_handler()
{
printf ("popup handler\n");
}

int main (argc,argv, envp)
int argc;
char **argv;
char **envp;
{
XtAppContext app_context;
Display *theDisplay;
Widget shell1, shell2, shell3, shell4;
Widget label, DrawWindow, WindowPopupMenu;
Arg al[10];
int ac;
Atom delwinAtom1, delwinAtom2, delwinAtom3, delwinAtom4;
XmString xms;

#ifdef MULTIPLE_APP_SHELLS
printf ("This version will demonstrate a problem if you Close P2.\n");
printf ("Since there are multiple appshells, closing (destroying) P2 cause the app to exit.\n");
#else
#ifdef POPUP_SHELL
printf ("This version uses XtCreatePopupShell rather than XtAppCreateShell \n");
#else
printf ("Compile with '-DMULTIPLE_APP_SHELLS' to demonstrate a problem.\n");
#endif
#endif

#ifdef BEFORE_CREATE
printf ("This version adds the XmNdeleteResponse _before_ the shell is created.\n");
#else
printf ("This version adds the XmNdeleteResponse _after the shell is created.\n");
#endif

XtToolkitInitialize ();
app_context = XtCreateApplicationContext ();

theDisplay = XtOpenDisplay ( app_context, NULL,
"my_program", "ProgramClass",
NULL, 0, &argc, argv);

/* --------------------- BEGIN P1 -------------------- */
ac = 0;
XtSetArg(al[ac], XmNx, 0); ac++;
XtSetArg(al[ac], XmNy, 0); ac++;
XtSetArg(al[ac], XmNwidth, 350); ac++;
XtSetArg(al[ac], XmNheight, 200); ac++;
XtSetArg (al[ac], XmNtitle, P1_TITLE); ac++;
#ifdef BEFORE_CREATE
XtSetArg (al[ac], XmNdeleteResponse, XmDO_NOTHING); ac++;
#endif

/* The ONLY applicationShell unless MULTIPLE_APP_SHELLS is defined. */

shell1 = XtAppCreateShell ("shell1", "ProgramClass",
applicationShellWidgetClass, theDisplay, al, ac);

/* Tell mwm to exec CloseCB when close is detected. */
delwinAtom1 = XmInternAtom (XtDisplay(shell1),
"WM_DELETE_WINDOW", False);
XmAddWMProtocolCallback (shell1, delwinAtom1, CloseCB, P1_TITLE);

#ifndef BEFORE_CREATE
XtVaSetValues( shell1, XmNdeleteResponse, XmDO_NOTHING, NULL);
#endif

/* --------------------- BEGIN P2 -------------------- */
ac = 0;
XtSetArg(al[ac], XmNx, 375); ac++;
XtSetArg(al[ac], XmNy, 0); ac++;
XtSetArg(al[ac], XmNwidth, 350); ac++;
XtSetArg(al[ac], XmNheight, 200); ac++;
XtSetArg (al[ac], XmNtitle, P2_TITLE); ac++;
#ifdef BEFORE_CREATE
XtSetArg (al[ac], XmNdeleteResponse, XmDESTROY); ac++;
#endif

#ifdef MULTIPLE_APP_SHELLS
shell2 = XtAppCreateShell ("shell2", "ProgramClass",
applicationShellWidgetClass, theDisplay, al, ac);
#else
#ifdef POPUP_SHELL
/*
* NOTE use of XtCreatePopupShell (not XtCreateMAnagedWidget) and
* topLevelShellWidgetClass (not applicationShellWidgetClass).
* Parent of topLevelShell is applicationShell.
* Use XtPopup rather than XtRealize for topLevelShell.
*/
shell2 = XtCreatePopupShell ("shell2",
topLevelShellWidgetClass, shell1, al, ac);
#else
shell2 = XtAppCreateShell ("shell2", "ProgramClass",
topLevelShellWidgetClass, theDisplay, al, ac);
#endif
#endif

/* Tell mwm to exec CloseCB when close is detected. */
delwinAtom2 = XmInternAtom (XtDisplay(shell2),
"WM_DELETE_WINDOW", False);
XmAddWMProtocolCallback (shell2, delwinAtom2, CloseCB, P2_TITLE);

#ifndef BEFORE_CREATE
XtVaSetValues( shell2, XmNdeleteResponse, XmDESTROY, NULL);
#endif

/* --------------------- BEGIN P3 -------------------- */
ac = 0;
XtSetArg(al[ac], XmNx, 750); ac++;
XtSetArg(al[ac], XmNy, 0); ac++;
XtSetArg(al[ac], XmNwidth, 350); ac++;
XtSetArg(al[ac], XmNheight, 200); ac++;
XtSetArg (al[ac], XmNtitle, P3_TITLE); ac++;
#ifdef BEFORE_CREATE
XtSetArg (al[ac], XmNdeleteResponse, XmUNMAP); ac++;
#endif

#ifdef MULTIPLE_APP_SHELLS
shell3 = XtAppCreateShell ("shell3", "ProgramClass",
applicationShellWidgetClass, theDisplay, al, ac);
#else
#ifdef POPUP_SHELL
/* See comments for shell2 */
shell3 = XtCreatePopupShell ("shell3",
topLevelShellWidgetClass, shell1, al, ac);
#else
shell3 = XtAppCreateShell ("shell3", "ProgramClass",
topLevelShellWidgetClass, theDisplay, al, ac);
#endif
#endif

/* Tell mwm to exec CloseCB when close is detected. */
delwinAtom3 = XmInternAtom (XtDisplay(shell3),
"WM_DELETE_WINDOW", False);
XmAddWMProtocolCallback (shell3, delwinAtom3, CloseCB, P3_TITLE);

#ifndef BEFORE_CREATE
XtVaSetValues( shell3, XmNdeleteResponse, XmUNMAP, NULL);
#endif

/* --------------------- BEGIN P4 -------------------- */
ac = 0;
XtSetArg(al[ac], XmNx, 0); ac++;
XtSetArg(al[ac], XmNy, 250); ac++;
XtSetArg(al[ac], XmNwidth, 350); ac++;
XtSetArg(al[ac], XmNheight, 200); ac++;
XtSetArg (al[ac], XmNtitle, P4_TITLE); ac++;
#ifdef BEFORE_CREATE
XtSetArg (al[ac], XmNdeleteResponse, XmDO_NOTHING); ac++;
#endif

#ifdef MULTIPLE_APP_SHELLS
shell4 = XtAppCreateShell ("shell4", "ProgramClass",
applicationShellWidgetClass, theDisplay, al, ac);
#else
#ifdef POPUP_SHELL
/* See comments for shell2 */
shell4 = XtCreatePopupShell ("shell4",
topLevelShellWidgetClass, shell1, al, ac);
#else
shell4 = XtAppCreateShell ("shell4", "ProgramClass",
topLevelShellWidgetClass, theDisplay, al, ac);
#endif
#endif

/* Tell mwm to exec CloseCB when close is detected. */
delwinAtom4 = XmInternAtom (XtDisplay(shell4),
"WM_DELETE_WINDOW", False);
XmAddWMProtocolCallback (shell4, delwinAtom4, CloseCB, P4_TITLE);

#ifndef BEFORE_CREATE
XtVaSetValues( shell4, XmNdeleteResponse, XmDO_NOTHING, NULL);
#endif

/* just for fun */
ac = 0;
WindowPopupMenu = XmCreatePopupMenu(shell1, "PopupMenu", al, ac);
XtAddEventHandler( shell1, ButtonPressMask, FALSE, popup_handler,
WindowPopupMenu);

ac = 0;
xms = (XmString) XmStringCreateLocalized ( "Button3 = popup; Button2 = DnD.");
XtSetArg(al[ac], XmNlabelString, xms); ac++;
XtSetArg(al[ac], XmNshadowThickness, 2); ac++;
label = XmCreateLabel (shell1, "label", al, ac);
XtManageChild ( label );

XtRealizeWidget( shell1 );

/* NOTE use of XtPopup rather than XtRealizeWidget for topLevels */

#ifdef MULTIPLE_APP_SHELLS
XtRealizeWidget( shell2 );
XtRealizeWidget( shell3 );
XtRealizeWidget( shell4 );
#else
#ifdef POPUP_SHELL
XtPopup ( shell2, XtGrabNone );
XtPopup ( shell3, XtGrabNone );
XtPopup ( shell4, XtGrabNone );
#else
XtRealizeWidget( shell2 );
XtRealizeWidget( shell3 );
XtRealizeWidget( shell4 );
#endif
#endif

XtAppMainLoop (app_context);
}


-----------------------------------------------------------------------------
END OF PART THREE