Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hp-pcd!hpcvlx!keith
From: keith@hpcvlx.cv.hp.com (Keith Taylor)
Newsgroups: comp.windows.x
Subject: Re: WM_SAVE_YOURSELF
Message-ID: <100920282@hpcvlx.cv.hp.com>
Date: 28 Jan 91 18:29:57 GMT
References: <1991Jan22.064227.4656@agate.berkeley.edu>
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 36

It looks like you have a good understanding of what f.kill does in mwm,
so I'll just comment on a couple of points.

> 
> When WM_SAVE_YOURSELF (and not WM_DELETE) is noted, the window manager sends
>   the WM_SAVE_YOURSELF message, unmaps the client's window, and then appears to
>   wait for a client response.  If the client responds, the application quits
>   by some mysterious mechanism after the WM_SAVE_YOURSELF callback returns.
>   If the client does NOT respond, the client gets wasted anyway.
> 
> MY QUESTION IS: How do I prevent my application from getting blown away by
>   the WM_SAVE_YOURSELF mechanism?  Is this even possible according to ICCC?
>   (I thought it was, but perhaps I am reading ICCCM wrong?).

WM_SAVE_YOURSELF is a session management protocol that essentially asks
the client to checkpoint itself. Its use by mwm is a vestige of the
days before WM_DELETE_WINDOW.  The thinking at the time was that giving
the client *some* warning before blasting its connection was better than
no warning at all.

What mwm does is send the WM_SAVE_YOURSELF message and wait for some 
time (quitTimeout) for WM_COMMAND to be updated. When WM_COMMAND is 
updated or the timeout expires, mwm kills the X connection to the client. 

> 
> What I would like to do is prompt the user with a dialog box that says "Do you
>   really want me to quit?" and if the user clicks "No", then I'd like to go on
>   with life and not get killed (Or have my window unmapped for that matter!).
> 

Use WM_DELETE_WINDOW.


Keith M. Taylor		keith@cv.hp.com	
Hewlett-Packard
Corvallis, Oregon