Dumping gnome-smproxy in 2.14
- From: Mark McLoughlin <markmc redhat com>
- To: Desktop Devel <desktop-devel-list gnome org>
- Subject: Dumping gnome-smproxy in 2.14
- Date: Fri, 22 Jul 2005 14:54:08 +0100
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]