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

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

Matthias Ettrich wrote:
> We need to figure out a way to identify those windows when they startup
> again. Most certainly WM_COMMAND won't work here. But what about the class
> hint?
That is what the ``store settings'' option does.

> But isn't the whole point of this to make session 
> management work with emacs and friends?

That would be solved by faking commands in Client::wmCommand() 
on the basis of the class hints.   There would be problems
when emacs has several X11 windows.

I scanned my binaries for apps supporting the save_yourself thing.
Found emacs, vim, x3270, netscape.
Not a very impressive list.

Found that netscape 4.76 (unlike 4.72) implements a trick.
Each netscape window contains a WM_CLIENT_LEADER property
that points to an unmapped window whose sole purpose is to
carry WM_COMMAND and perform the WM_SAVE_YOURSELF thing.
That breaks the patch :-(.

Found the X11R6 ``smproxy'' program that wraps all legacy session 
management within its own session managed configuration.
The man page and the source code is very instructive.  
Three problems
   - both kwin and smproxy will revive WM_COMMAND windows
   - kwin's window recognition is not powerful enough (must use
classhints)
   - smproxy leaves its config files around (clutter clutter)

On the other hand, smproxy is able to handle remote windows
such as xterms open on other machines on the same network.
It also does the WM_CLIENT_LEADER thing that netscape wants.

* * *

Conclusion:

I make now a clear distinction between the session management
(dealing with application) and the window matching code (trying
to apply the proper geometry to new windows).  The latter has 
to be in the window manager.

I see several solutions:

1- Use smproxy (using option -restore <filename> to avoid clutter),
   Remove kwin's legacy sm code.  Upgrade kwin window matching code to
use,
   in order of preference, sessionid+windowrole,
wmcommand+wmclientmachine,
   or classhints.

2- Upgrade kwin's legacy sm code to handle WM_CLIENT_LEADER and
   WM_CLIENT_MACHINE.  Upgrade kwin window matching code to use,
   in order of preference, sessionid+windowrole,
wmcommand+wmclientmachine,
   or classhints.  Make sure to maintain a clear distinction between
   the legacy sm code, and the window matching code.

3- Give legacy sm capabilities to ksmserver (smproxy sources are
useful).  
   Remove legacy sm from kwin. Upgrade kwin window matching code to use,
   in order of preference, sessionid+windowrole,
wmcommand+wmclientmachine, 
   or classhints.

I could do 1 or 2 if you wish.
Solution 3 is more logical and allows for a 
ksmserverrc control panel option for enabling legacy sm.   
Solution 1 could be a preparatory step for solution 3.

In any cases, my patch, as it is now, is insufficient.
Let me know if I can do something useful there.

- Leon Bottou

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