smproxy and gnome-smproxy break the XSMP

[Olivier Chapuis]

On Thu, Jul 31, 2003 at 08:55:56PM +0200, Lubos Lunak wrote:
> On Thursday 31 of July 2003 17:00, Havoc Pennington wrote:
> > On Thu, Jul 31, 2003 at 03:25:23PM +0200, Olivier Chapuis wrote:
> > > 1. Remove smproxy from XFree and gnome-smproxy from GNOME with
> > > the hope that all alive applications which use the old sm protocol
> > > will switch to the new one. Probably a bad solution ...? By the
> > > way it seems that KDE does not have and do not run by default a
> > > sm proxy.
> >
> > I agree with Owen that this is right, the smproxy stuff is just a bad
> > idea.
> >
> > I think KDE does have some "try to manage non-SM apps" code also, I
> > don't remember the details though. Someone was claiming that KDE
> > successfully restarts netscape/mozilla for example.
> 
>  Confirmed. Even though Mozilla here restarted as mozilla-bin does not really 
> restart, most probably missing some LD_LIBRARY_PATH that's set up in the 
> mozilla script.
> 

Do not happen here ... maybe my KDE is too old (kdebase-3.0.3).

> >
> > My memory is that I tried to find the code that did this and didn't
> > succeed.
> 
>  Used to be in KWin, now in ksmserver.
> 
> > Anyway, so I don't know whether it would have the same issue
> > or not.
> 
>  I don't think I quite understand the problem, but we use WM_SAVE_YOURSELF 
> only on windows which don't have the SM_CLIENT_ID property, and those apps 
> running under different session manager (weird, does somebody really do 
> that?) should have it anyway.

A priori SM_CLIENT_ID is set by the application itself and not the
session manger (ICCCM2 section 5.1) (however, it is the session
manager which gives to the app the client id).  Of course an other
application can set it: gnome-smproxy do that (not smproxy), I do not
know why (maybe an artifact for metacity?). I know no session manager
which sets the SM_CLIENT_ID. The SM_CLIENT_ID is for the window manager
and at least xsm and gnome-session ignore properties on windows. They
use the XSMP protocol.

If ksmserver restart some non XSMP applications by using the old
protocol the problem I describe may happen (but here KDE re-start only
XSMP award applications).  However, if ksmserver monitors the
SM_CLIENT_ID property a sm can found a workaround by setting this
property. The SESSION_MANAGER property may allow ksmserver to know
that an other sm has "started" a given non XSMP award top level
window without using an artifact (claiming that a given app is 
XSMP compliant).

Regards, Olivier