From kde-bugs-dist Tue Mar 06 16:56:19 2001 From: Leon Bottou Date: Tue, 06 Mar 2001 16:56:19 +0000 To: kde-bugs-dist Subject: Bug#9394: Bug #9364: KDE2 session manager does not restart legacy apps (e.g emacs) X-MARC-Message: https://marc.info/?l=kde-bugs-dist&m=98390123531778 Matthias, I just received this email from Moritz Franosch and that prompted me into investigating the legacy session and spotting a few problems. ------------------------- Moritz Franosch wrote: > I've just read your bug report http://bugs.kde.org/db/93/9394.html > which says that in KDE 2 some non-KDE2 applications like emacs and > xterm are not restarted when loggin in next time. > I observed the same for KDE 2.1 and e.g. xemacs whereas other > applications like xosview _are_ restarted. > Have you found out more about the problem or solved it? > Thank you, > Moritz ------------------------- Let me first quote the essential parts of our previous exchanges on this subject (august 2000) ------------------------- > > > it is gone and will remain gone. Things like emacs and xterm don't support > > > WM_SAVE_YOURSELF either, but they define a WM_COMMAND. I'll add this kind of > > > pseudo session management to kwin again. All the applications you mentioned > > > will restart then (but not restore state). > > FYI: Note that while xterm does WM_COMMAND/WM_CLIENT_MACHINE, > > emacs seems to require a WM_SAVE_YOURSELF message : > > % xprop -name emacs@odeux.research.att.com > > ..... > > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, WM_SAVE_YOURSELF > > ..... > > WM_NAME(STRING) = "emacs@odeux.research.att.com" > xemacs doesn't even support WM_SAVE_YOURSELF. > We won't get emacs support then, I'm afraid. > Matthias ------------------------- We had a misunderstanding here (emacs vs xemacs) but I thought that you had other more serious bugs to chase after the release of kde2. It seems that: - ``xterm'' and ``xemacs'' sets WM_COMMAND and do not support WM_SAVE_YOURSELF - ``emacs'' and recent versions of ``xemacs'' not only support WM_SAVE_YOURSELF but will not set WM_COMMAND unless they receive a save-yourself message. It seems that KDE2.1 supports WM_COMMAND and XSM (since Moritz Franosh says that xterm works) but not WM_SAVE_YOURSELF (since emacs still does not work). Here is what the ICCCM manual says about WM_SAVE_YOURSELF: << Clients that want to be warned when the session manager feels that they should save their internal state (for exam- ple, when termination impends) should include the atom WM_SAVE_YOURSELF in the WM_PROTOCOLS property on their top- level windows to participate in the WM_SAVE_YOURSELF proto- col. They will receive a event as described in section 4.2.8 with the atom WM_SAVE_YOURSELF in its data[0] field. Clients that receive WM_SAVE_YOURSELF should place them- selves in a state from which they can be restarted and should update WM_COMMAND to be a command that will restart them in this state. The session manager will be waiting for a event on WM_COMMAND as a confirmation that the client has saved its state. Therefore, WM_COMMAND should be updated (perhaps with a zero-length append) even if its contents are correct. No interactions with the user are permitted during this process. Once it has received this confirmation, the session manager will feel free to terminate the client if that is what the user asked for. Otherwise, if the user asked for the ses- sion to be put to sleep, the session manager will ensure that the client does not receive any mouse or keyboard events. After receiving a WM_SAVE_YOURSELF, saving its state, and updating WM_COMMAND, the client should not change its state (in the sense of doing anything that would require a change to WM_COMMAND) until it receives a mouse or keyboard event. Once it does so, it can assume that the danger is over. The session manager will ensure that these events do not reach ... >> That means that if the windows supports protocol WM_SAVE_YOURSELF (checked using XGetWMProtocols), then one cannot be sure that WM_COMMAND is correct or even simply set. One must send a WM_SAVE_YOURSELF message and wait until WM_COMMAND gets updated. Kwin-CVS does not do that at the moment. Suggested change: kdebase/kwin/atoms.cpp: Add WM_SAVE_YOURSELF kdebase/kwin/client.cpp Modify Client::wmCommand() as follows: If XGetWMProtocols returns WM_TAKE_YOURSELF protocol Send WM_SAVE_YOURSELF message Wait for change in property WM_COMMAND (timeout?) Return XGetProperty(WM_COMMAND). kdebase/kwin/workspace.cpp calls Client::wmCommand() in two places. One is Workspace::storeSession() and should indeed to the TAKE_YOURSELF thing The other one is Workspace::takeSessionInfo(). I did not find where it is used and why. Another issue with WM_COMMAND: I do not think that kwin honors WM_CLIENT_MACHINE. Suppose I logout while having a XTERM running on another machine over the network. When I login again, I obtain a XTERM running on the local machine. That defeats the purpose. When WM_CLIENT_MACHINE is set, one could make wmCommand() return "xon thewmclientmachine thewmcommand". That would work if the client machine has the proper X authorization (i.e. it has access to the proper .Xauthority file or has been made an authorized host with xhost.) A further refinement would be to check the list of authorized hosts and return "xon thewmclientmachine -access thewmcommand" if the client machine is an authorized host. That would make it again an authorized host. Security issues there... Hope it helps. - Leon Bottou