Honestly, any reason to wait to 2.14? Luis
On 7/22/05, Mark McLoughlin <[EMAIL PROTECTED]> 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 > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
