Dumping gnome-smproxy in 2.14



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.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]