Re: Dumping gnome-smproxy in 2.14

Hi Mark,

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


Mark McLoughlin wrote:

	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

	Let me give some rationale on why it should go, though:

 - It causes heartbreaking bugs. Some examples:

     1) "Splash screen doesn't disappear"

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"

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"

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"

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"

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?


desktop-devel-list mailing list
desktop-devel-list gnome org

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