smproxy and gnome-smproxy break the XSMP

Lubos Lunak l.lunak at
Fri Aug 1 11:38:31 EEST 2003

On Friday 01 of August 2003 00:26, Olivier Chapuis wrote:
> 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:
> >
> >  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).

 I'm still not sure I understand the problem, but I think it's a bug in 
gnome-smproxy. Just like KDE, it simply has to check whether the app is XSMP 
app or not.

Lubos Lunak
KDE developer
SuSE CR, s.r.o.  e-mail: l.lunak at , l.lunak at
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic

More information about the xdg mailing list