[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    Bug#9394: Bug #9364: KDE2 session manager does not restart legacy apps (e.g   emacs)
From:       Leon Bottou <leonb () research ! att ! com>
Date:       2001-03-06 16:56:19
[Download RAW message or body]


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

[prev in list] [next in list] [prev in thread] [next in thread]