Re: Dumping gnome-smproxy in 2.14

[ghee teo <Ghee Teo Sun COM>]

Hi Mark,

   Do you know any of the major apps such as Mozilla, xterm require 
gnome-smproxy
to even work  for session restoration?

-Ghee

Mark McLoughlin wrote:

> Hi,
> 	gnome-smproxy is a little program in gnome-session which acts as an
> XSMP proxy for applications which don't support XSMP, but do support the
> obsolete WM_SAVE_YOURSELF ICCCM protocol.
>  
>
> 	Hopefully very few peole have a clue what all that means and that the
> people who do know what it means all agree that its time we dropped this
> thing.
>
> 	Let me give some rationale on why it should go, though:
>
>  - It causes heartbreaking bugs. Some examples:
>
>      1) "Splash screen doesn't disappear"
>
>         http://bugzilla.gnome.org/show_bug.cgi?id=118063
>
>         A rather innocous change - marking the gnome-session splash 
>         screen as _NET_WM_WINDOW_TYPE_SPLASH rather than 
>         override_redirect - made smproxy start acting as an XSMP proxy 
>         for gnome-session. Go figure.
>
>       2) "gnome-panel twice in session"
>
>          http://bugzilla.gnome.org/show_bug.cgi?id=309506
>
>          Basically, the panel used to delete the WM_CLIENT_LEADER 
>          property, we stopped doing that and then the window manager 
>          started screwing over the panel so we unset the SM_CLIENT_ID 
>          property and now smproxy is screwing us over.
>
>       3) "applet gets listed in session file"
>
>          http://bugzilla.gnome.org/show_bug.cgi?id=147691
>
>          If you open an applet's preferences dialog and save the 
>          session, the applet gets saved in the session. The splash 
>          screen doesn't go away when you log in, then.
>
>       4) "smproxy kills sdtprocess"
>
>          http://bugzilla.gnome.org/show_bug.cgi?id=81343
>
>          Some CDE app doesn't implement the WM_SAVE_YOURSELF protocol 
>          correctly and smproxy kills it. Workaround was to set some 
>          bizzarre CDE-specific properties on the root window. Don't 
>          ask me ...
>
>       5) "smproxy does not properly handle java session"
>
>          http://bugzilla.gnome.org/show_bug.cgi?id=85933
>
>          Java doesn't correctly implement the ICCCM and smproxy 
>          wouldn't proxy for Java apps. Some strage workaround in 
>          smproxy fixed it.
>
>  - This obsolete protocol that we're providing support for was 
>    deprecated at least a decade ago as far as I can make out. If apps 
>    haven't migrated to XSMP at this point, its likely they never will. 
>    So, if we decide now that we must continue to support this 
>    protocol, I don't see that there'll ever be a time when we can stop 
>    supporting it.
>
>  - Red Hat hasn't shipped enabled gnome-smproxy by default in a long, 
>    long time. I don't think anyone has complained.
>
>  - I'm sick to the back teeth of dealing with smproxy related issues. 
>    This is not some trivial zero-maintenance feature - its a feature 
>    which regularily sucks in significant amounts of people's time 
>    trying to track down and fix the truly obscure issues that crop up.
>
>  - It really is hard to justify spending any time on dealing with 
>    smproxy issues. What handful of obsolete apps are we supporting 
>    here? And to what end?
>
> Cheers,
> Mark.
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>