GNOME Bugzilla – Bug 556464
[PATCH] Add gconf key for warning about lame SM clients
Last modified: 2009-11-18 18:44:09 UTC
The dialog that warns about lame SM clients is frustrating. It doesn't let you cancel the logout, so the information it provides is too late. And even if it did let you cancel, you rarely care. I'm attaching a patch that adds a gconf key /apps/metacity/general/warn_on_lame_client_sm to toggle whether that dialog is displayed. It could be the base for an eventual 'Don't tell me again'-type checkbox. Or we could default it to false. :)
Created attachment 120677 [details] [review] Proposed patch Copyright Canonical
a) If the dialogue is so lame, why would we want to keep it around at all for anyone? b) Am I missing something, or did you not define finish_interact()?
a) I didn't call the dialog lame (the code refers to non-SM clients as 'lame'), though it's a fair accusation. :) I'd be in favor of removing it, and would submit a patch to do so if desired. I was taking a baby step approach. b) finish_interact() is defined lower in the file, I just forward declared it because I used it further up in the file.
a) I prefer not to add gconf settings as baby steps, because in the end they stay in for ever, and then we have hundreds of them. I'd rather just have the patch, and then if some distros want to keep this dialogue they can just reverse-apply it. b) ah, thanks. It's remiss of us if we didn't prototype everything already, so good catch. Other folks reading this: do you have any arguments pro or con keeping the dialogue?
There is an old bug or two with discussion of this, I'm pretty sure, if you want pros and cons and original rationale.
bug 84859 and bug 91689 are some old ones, though they don't seem to be all that enlightening. They do point out that the purpose of the dialog is to blame apps. Otherwise, if SM fails, people don't know where the bug is. Of course my view is that XSMP should just die, but if we're hypothetically trying to make it work, a dialog like this may be needed to ensure bug reports against whichever apps do not support XSMP.
If it's the view of the metacity maintainers that the dialog may have some purpose, but they're not excited about it, then my gconf patch has more relevance: It's the time honored role of gconf keys to handle the burden created by developer indecision. ;) Truth be told, I think the contents of this 'lame clients' dialog would fit in better with the dialog that is thrown up by gnome-session saying, for example, 'gedit has unsaved contents, maybe you want to go futz with it first?' That dialog has a cancel button and also deals with apps that would lose their state if you continue. Seems like a natural place to include unmanaged apps. But that dialog seems to have changed in recent times to iterate over the 'session inhibiting' apps, not the 'managed with unsaved changes' apps?
I would say users who get stuck dealing with gconf keys are the ones who handle the burden of developer indecision. There is no reason to be indecisive here. If anyone cares about XSMP, then they should file bugs vs. the apps that show in this dialog, and keep the dialog. If nobody cares about XSMP, then remove the dialog. And consider removing the XSMP support entirely, for that matter. I believe the dialog opened by gnome-session doesn't know about non-SM apps because they don't register with gnome-session, so showing the non-SM apps in that dialog would involve some sort of complex protocol to relay the list of bad apps from the WM to gnome-session.
You're probably already aware of this, Havoc, but it does seem that GNOME (or at least William McCann) is trying to deprecate XSMP -- http://live.gnome.org/SessionManagement/GnomeSession optimistically refers to "legacy XSMP apps." Such newfangled DBUS session management appears to limit the scope of 'state' to just whether or not an application should be restarted. Which is a much smaller scope than XSMP tried to cover (telling apps to save the exact state of the app). This more limited scope suggests a less urgent need for this dialog under the new session overlords. Obviously, the new session management scheme isn't ready today, but it points towards a XSMP-less future.
Bug 584723 has a patch to remove the dialog entirely, which is more appropriate than adding a GConf key - nut also see the comment there about why the dialog might have started appearing. *** This bug has been marked as a duplicate of bug 584723 ***