Created attachment 78737 [details] [review]
Proposed (untested) patch

This is the sort of ifdef that will break all the time because nobody tests it. What is the rationale for it? If it's just for embedded systems or something then there's a one-line patch the systems integrator could maintain themselves...

If there is some good reason to have this in configure.in, I think putting the #ifdef only around the actual warning or otherwise ensuring it's a very small amount of #ifdef code would be good for avoiding breakage.

"What is the rationale for it?"

http://www.mail-archive.com/usability@gnome.org/msg02968.html

"If there is some good reason to have this in configure.in, I think putting the
#ifdef only around the actual warning or otherwise ensuring it's a very small
amount of #ifdef code would be good for avoiding breakage."

Initially, I wanted to solve it according to your suggestion, but not calling its helpers resulted in a "unused function" warning with GCC.

A quick test revealed that this seems to work properly, btw - i.e. SM-less clients are ignored.

I don't see the mention of this issue in that thread you linked to?

There are two different rationales needed here -
 1) why the warning about broken apps is bad in some end user 
    scenarios
 2) why the warning about broken apps is bad *only for some people 
    who compile metacity* (distributions, gnome developers, who else ... ?)
    which would dictate a configure option.
    If it's bad *always* then we just remove this code, if it's bad
    for *some end users* that may not correspond to *people building 
    metacity* then we need an automagic decision by metacity or 
    failing that a gconf option, rather than a compile-time option

> I don't see the mention of this issue in that thread you linked to?


I see, it looks like I misunderstood the thread.

The poster stated

"To me, ideally, if an application is not going to prompt to save unsaved
work it should exit silently without reappearing on the screen.  Do people
agree with this?"

So translated into a technical language, this might be interpreted as "SM aware apps that don't show an interactive save dialog pop up on logout" which is probably a consequence of the WM being quit first, i.e. bug 144107.

My interpretation of it was "on logout, we mess around with apps that are not SM aware", which seems to be wrong.



Regarding the warning, I still think it isn't useful but distracting, as the user can't correct anything, and app authors are usually aware whether their apps support SM or not. So I think 1) applies and you are totally correct that this should be decided for all users. I'm marking this patch as "rejected", and CCing usability.

Renaming bug report from
  Allow to disable lame client warning
to
  Disable lame client warning

Created attachment 78748 [details] [review]
Proposed patch that will remove the lame clients dialog

This patch will remove the

  These windows do not support \"save current setup\" and will have to be
  restarted manually next time you log in.

dialog.

We don't "save current setup" automatically on logout anymore, right?

I think this dialog only shows up if you explicitly ask to save the session, in which case telling you your explicit request won't work seems plausible.

Of course, my general view on XSMP is that it should be taken out and shot precisely because there are and will always be so many apps that it won't work right with, clearly the right usability answer is that instead of having a "this won't work" dialog we should avoid offering features that won't work.

While we do have features that won't work, telling people seems possibly nicer than just silently not working, I suppose...

I think the original idea here was largely to help get bug reports about "xyz didn't come back after I saved session" sent to the bug tracker for xyz instead of to gnome-session or metacity, which is where most users would assume they should go.

IIRC, Ubuntu has "Save current setup" on by default instead of having a "Save current setup" checkbox in the logout dialog.

To make this dialog useful, I suggest:
*   Make it an actual dialog, replacing the "Close" button with "Cancel" and
    "$ACTION Anyway" (where $ACTION = "Log Out", "Shut Down", or "Restart").
*   Make the list of windows live, each disappearing from the list as it is
    closed. (The dialog itself should close automatically once the list has
    been empty for a couple of seconds.)
*   Change the message so that it doesn't leave the user helpless. For
    example: "Some programs will not resume automatically when you next log
    in. You may want to close them yourself now, to ensure you don't lose
    any work."
*   Reduce the height of the dialog, so that it's more obvious you can
    access other windows while it's open.
All these would be improvements alone, but they'd be best working together.

There was another bug already open about this; I've copied some of the comments from this bug (including mpt's suggestions) into the other one.

*** This bug has been marked as a duplicate of 160712 ***