GNOME Bugzilla – Bug 95111
gnome-session-properties Quit confirmation dialog is not HIG compliant
Last modified: 2007-01-08 14:06:38 UTC
Package: control-center Severity: minor Version: 2.1.0 Synopsis: gnome-session-properties Quit confirmation dialog is not HIG compliant Bugzilla-Product: control-center Bugzilla-Component: other capplets Description: gnome-session-properties' "Some changes hat not been saved" quit confirmation dialog has Cancel and OK buttons. It should have "Cancel", "Don't Save" and "Save" buttons or something similar ------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-10-07 16:14 ------- The original reporter (mawarkus@t-online.de) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, control-center-maint@bugzilla.gnome.org.
Created attachment 16858 [details] [review] Patch against gnome-2-2
Moving to GNOMEVER2.3 and adding PATCH keyword so it shows up on the radar.
Can we get this reviewed and commited if it's ok please?
Moving session properties bugs into the relevant component. Sorry for the e-mail spam (it's finished now): filter on "Andrew doing reassignment work" to get rid of it.
Apply apply apply!
Does this even apply any longer?
I would suggest using the similar dialog from gedit, I'll attach a screenshot. I don't know if this patch will apply.
Created attachment 30869 [details] Screenshot of Gedit's Save/Don't Save confirm dialog
Adding usability-maint to get other opinions. If there are none, this seems like an nice bug for new hackers to work on.
Adding easy-fix keyword to this one.
*** Bug 113865 has been marked as a duplicate of this bug. ***
Created attachment 36049 [details] [review] New HIG patch This patch is against current CVS and makes the dialog as close to the HIG as I can get without re-implementing large parts of GtkMessageDialog. Look at http://developer.gnome.org/projects/gup/hig/2.0/windows-alert.html#alerts-confirmation for rationale of any changes. I stole the time-to-text function with slight modification from gedit. On my machine, there is odd wrapping behavior. The primary text is not wrapped, but the secondary text is wrapped after the number, halfway across the dialog. It does not seem to be due to anything I do, and I'm tempted to say this is a bug in GtkMessageDialog. Do other people see this?
Wow. Michael, this is great! Think you can provide a screenshot? I hate this dialog, and I'd love to see it updated. Mark- POKE. :)
Created attachment 36433 [details] Screenshot of dialog with new patch (patch 36049) This is what it looks like with my patch. Again, the secondary text wraps for an unknown reason... Can others confirm if this is my broken system or my broken code?
Wraps before "seconds" here as well.
Is that countdown in seconds really needed ? I would say "Any change you made will be lost" or somthing like that. Imagine i push the quit button on the manager, then i switch desktop, go drink a coffe, then come back and see the dialog that says changes of the last 20 seconds will be lost, what does that mean ? i didn't change anything in the last 20 seconds, it was an hour ago ! Alternatively, the countdown should be "real-time" in the dialog message, but i don't know if it's that good..
Raphael, I think that scenario could be extended to a lot of things besides quit warnings. I think the larger problem there is the user ignoring warning dialogs and switching desktops (if the user switched desktops before the warning dialog came up, we have a performance problem instead). If you read the warning when it popped up, you won't be suprised. Gedit now has a dialog that looks very much like the dialog in my patch, using a non-real-time count. The GIMP does a real-time count. I'd like to get a usability person to chime in on real-time versus not.
Well, although it's not what the HIG currently suggests, you could always avoid the whole real-time/non-real-time debate by saying 'changes made since <time of last change>' rather than 'changes made in the last <period of time>'. Personally I think real-time counters in alerts look kind of gimmicky (except perhaps when counting down to some event that you might want to interrupt, like a system shutdown), and aren't really ideal for screenreaders. And a non-real-time counter is, as Raphael said, just plain wrong if you don't notice it straight away.
Did we ever get consensus on this change?
I committed the patch without the time. It's enough, IMHO. Thanks!
Forgot to close the bug.