scott@scam.Berkeley.EDU (Scott Silvey) (01/22/91)
I posted about a week ago about the WM_SAVE_YOURSELF protocol (ICCC). I am having trouble getting my programs to respond to this message properly and I was wondering if anyone out there knows how to do this. My understanding of the ICCCM is that all one needs to do is to "tickle" the WM_COMMAND property on the client window by setting it to "" (null string). Is this correct? When I do this, my callback runs but the client window is immediately unmapped by mwm and when the callback returns, the application is killed. I would like to know how to avoid being blown away by this protocol if the user decides to avoid it. Thanks. PS: I included a sample program in my earlier posting... -- /-----------------------------------------------------------------------------\ | Scott Silvey | Ronald Reagan on Pac Man: | | scott@xcf.berkeley.edu | "Someone told me it was a round thing that gobbles | | Flames to /dev/null. | up money, but I thought that was Tip O'Neill." | \-----------------------------------------------------------------------------/
dex@hpcvlx.cv.hp.com (Dex Smith) (01/25/91)
In your first message, you mention that you are testing your "save yourself"
callback by choosing the Close command in the window menu. The "save
yourself" protocol described in ICCCM is intended for use with session
managers, and is not related to the Close button. So, there are really
two questions here:
FIRST QUESTION:
* What should an application do to support session management?
1. Create (intern) a "save yourself" atom. Be sure you call
XInternAtom() after realizing your top-level shell.
saveYourselfAtom = XInternAtom(XtDisplay(top_level),
"WM_SAVE_YOURSELF", False);
Where saveYourselfAtom is declared as type "Atom."
2. Add a "save session" callback routine. This function should save
whatever application-specific data is necessary to fully restore
the application to its current state (just as though it was
never killed).
Within the "save session" callback, your application should set the
WM_COMMAND property. Session managers watch for this to know when
your application is done saving itself. (There is some timeout
period, I believe, for applications that don't respond.) You can
set this property with the XSetCommand() function.
3. Add a protocol callback that invokes the "save session" callback
routine. Something like this:
XmAddWMProtocolCallback (top_level, saveYourselfAtom,
SaveSessionCB, NULL);
Where SaveSessionCB() is the routine written in step 2.
Now, whenever a session manager sets the "save yourself" property, your
application will save its session information.
SECOND QUESTION:
* How can an application respond to the window manager's Close command?
The idea is that the Close command should work just like the Exit
command in your File menu (if you have one). Refer to the OSF/Motif
style guide for more information on the File menu.
For example, if you File menu's Exit command displays a confirmation
dialog, so should the Close command in the window menu. So, how does
your appliation know when the user has chosen Close? Like this:
1. Create a "delete window" atom. Something like this:
delWinAtom = XInternAtom(XtDisplay(top_level),
"WM_DELETE_WINDOW", False);
2. Set the XmNdeleteResponse resource (for your top-level shell)
to XmDO_NOTHING. This prevents the window from being automatically
destroyed by the Close command (ie. the behavior you described).
3. Add a protocol callback that calls the same routine that the
Exit button in your File menu calls (ExitCB(), in this example).
XmAddWMProtocolCallback (top_level, delWinAtom, ExitCB, NULL);
I hope this is what you are looking for.
- Dex Smith
Hewlett-Packard Company
Corvallis, Oregon
dex@hpcvlx.hp.comscott@graft.Berkeley.EDU (Scott Silvey) (01/26/91)
dex@hpcvlx.cv.hp.com (Dex Smith) writes: |> In your first message, you mention that you are testing your "save yourself" |> callback by choosing the Close command in the window menu. The "save |> yourself" protocol described in ICCCM is intended for use with session |> managers, and is not related to the Close button. Thank you for your volumous and clearly outlined response! Unfortunately, you didn't quite adress my questions which is no doubt due to the briefness of my second posting (the first one was more thorough and included a program which illustrates the problem I am having with WM_SAVE_YOURSELF). Here is the behavior I am actually seeing from mwm: When one selects the "Close" command, mwm checks for the two protocols WM_DELETE and WM_SAVE_YOURSELF. If neither is supported, mwm gets rather fascist and simply whacks the client's X connection. When WM_DELETE is noted in the WM_PROTOCOLS property, mwm sends the WM_DELETE message and doesn't bother the client again, assuming that it will be socially compliant and attempt to shut itself down. I am able to get this mechanism to work properly. 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?). 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!). /-----------------------------------------------------------------------------\ | Scott Silvey | Ronald Reagan on Pac Man: | | scott@xcf.berkeley.edu | "Someone told me it was a round thing that gobbles | | Flames to /dev/null. | up money, but I thought that was Tip O'Neill." | \-----------------------------------------------------------------------------/
keith@hpcvlx.cv.hp.com (Keith Taylor) (01/29/91)
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
grp@Unify.com (Greg Pasquariello) (01/29/91)
In article <1991Jan25.201354.17242@agate.berkeley.edu>, scott@graft.Berkeley.EDU (Scott Silvey) writes: > 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?). > After the session manager sends the WM_SAVE_YOURSELF, and the application responds, the session manager should continue doing what it was doing - term- inating the application in this case, because the use selected CLOSE. In practice, most session managers don't wait forever for a response, so after some time, they generally continue anyway. So, if the user selected CLOSE, there is no way via the ICCCM to prevent your window from being wiped out. What happens when WM_DELETE _and_ WM_SAVE_YOURSELF are present? > 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!). > Because you can't prevent the window from being destroyed, it doesn't make sense to prompt the user, and in fact, this is prohibited by the ICCCM in 5.2.1. > | Scott Silvey > | scott@xcf.berkeley.edu -- --- Greg Pasquariello Unify Corporation grp@Unify.Com
gjw@spurr.wr.usgs.GOV (Gregory J. Woodhouse) (02/01/91)
Assume an application supports both the WM_DELETE and WM_SAVE_YOURSELF proto- cols. Under what normal circumstgances will olwm send a save yourself request to the application? What about mwm? (I expect my current project to be used in both environments.) No doubt this was covered some how in the recent discussion of this protocol, but (excuse alert!) I haven't really been able to read my mail carefully enough to tell these past few days. Now for the really interesting question: Process A knows process B's pid, and process B supports the save yourself protocol. Can process A kill process B and invoke this protocol? Can process B arrange for this to happen? Ultimately, I want process A to be able to kill process B and then restart it at a later time, but in the state in which it exited. What I can do is have it write a command on the root window (to what I call _XP_COMMAND), but I'd think this all ought to involve the save yourself protocol somehow. Thanks! Gregory Woodhouse gjw@ags.wr..usgs.gov
scott@graft.Berkeley.EDU (Scott Silvey) (02/02/91)
gjw@spurr.wr.usgs.GOV (Gregory J. Woodhouse) writes: |> Assume an application supports both the WM_DELETE and WM_SAVE_YOURSELF proto |> cols. Under what normal circumstances will mwm send a save yourself request |> to the application? Well, I can tell you this: When the user does something to invoke mwm's f.kill function, f.kill first looks for WM_DELETE. If it doesn't find it, it looks for WM_SAVE_YOURSELF. If it doesn't find this, it just blows the client away without warning. "Quick, Massive, and Decisive." |> Ultimately, I want process A to be able to kill process B and restart it |> at a later time, but in the state in which it exited. What I can do is have |> it write a command on the root window (to what I call _XP_COMMAND), but I'd |> think this all ought to involve the save yourself protocol somehow. Try to avoid using the root window as much as possible, since every time you tweak something, you will wake up a myriad of sleeping processes that are waiting for new and unusual things to happen there... Use clientMessage events or, if you must, WM_DELETE. According to ICCCM, a client can't avoid being shut down by a WM_SAVE_YOURSELF message. However, WM_DELETE can be overridden by the client and there is no nasty timeout in case you have a lot to do to save your state. /-----------------------------------------------------------------------------\ | Scott Silvey | DOD Spokesman Pete Williams on Cruise Missiles: | | scott@xcf.berkeley.edu | "We just don't discuss that capability. I can't | | | tell you why we don't discuss it because then I'd | | Flames to /dev/null | be discussing it." | \-----------------------------------------------------------------------------/
bill@polygen.uucp (Bill Poitras) (02/02/91)
In article <1991Jan25.201354.17242@agate.berkeley.edu> scott@xcf.berkeley.edu writes: >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?). I don't think you prevent WM_SAVE_YOURSELF from blowing you away. You have to maken sure that WM_PROTOCOLS window property is not set for your application. In Motif, you should make sure that WM_SAVE_YOURSELF is not being set. For further information, consult the Motif Programmer's Guide. In the version 1.0 manual, this is section 8.8.2 Protocol Manager Functions. > >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!). According to ICCCM (pg 39) "Clients receiving WM_SAVE_YOURSELF should place themselves in a state from which they can be restarted ... No interactions with the user are permitted during this process." So if WM_SAVE_YOURSELF is used you can't let the user save the changes it has made. +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton mit-eddie | | (bill) | Waltham, MA USA | bu sunne}!polygen!bill | | | FAX (617)890-8694 | bill@polygen.com | +-----------------+---------------------------+-----------------------------+
mikew@fx.com (Mike Wexler) (02/05/91)
bill@polygen.uucp (Bill Poitras) writes: >In article <1991Jan25.201354.17242@agate.berkeley.edu> scott@xcf.berkeley.edu writes: >>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?). >I don't think you prevent WM_SAVE_YOURSELF from blowing you away. You >have to maken sure that WM_PROTOCOLS window property is not set for >your application. In Motif, you should make sure that WM_SAVE_YOURSELF >is not being set. For further information, consult the Motif Programmer's >Guide. In the version 1.0 manual, this is section 8.8.2 Protocol Manager >Functions. The proper thing for him to have the WM_DELETE_WINDOWS protocol in his WM_PROTOCOLS property to handle his dialog box asking the user to save his changes. He SHOULD have WM_SAVE_YOURSELF in his WM_PROTOCOLS if he supports that protocol, whether or not he is targeting Motif. This works fine and is very useful even under Motif if you have appropriate tools. -- Mike Wexler (mikew@fx.com)