GNOME Bugzilla – Bug 609959
screensaver won't activate when a grab is in place
Last modified: 2012-08-23 18:17:13 UTC
i had the computer sitting in the activities overview. then i went to watch a movie. i came back and the screensaver still hadn't activated. i clicked on a window in the little window preview / workspace area. it started to load, then the screensaver took over. kind of annoying to have the screensaver not pop up at all when i'm gone, then pop up pretty much right when i'm ready to go again.
Created attachment 181356 [details] [review] Hide the overview when the screensaver is activated If the overview is shown, gnome-screensaver cannot grab the input and lock the screen, thus connect to gnome-session in the overview and hide it when about to show the screensaver.
(In reply to comment #1) > Created an attachment (id=181356) [details] [review] > Hide the overview when the screensaver is activated > > If the overview is shown, gnome-screensaver cannot grab the input > and lock the screen, thus connect to gnome-session in the overview > and hide it when about to show the screensaver. Can't we ungrab and regrab instead? (pop/push) Not sure whether we can do it at the right time but for the user it is kind of odd to not be in the state where he/she was before the screensaver activated.
(In reply to comment #2) > (In reply to comment #1) > > Created an attachment (id=181356) [details] [review] [details] [review] > > Hide the overview when the screensaver is activated > > > > If the overview is shown, gnome-screensaver cannot grab the input > > and lock the screen, thus connect to gnome-session in the overview > > and hide it when about to show the screensaver. > > Can't we ungrab and regrab instead? (pop/push) > Not sure whether we can do it at the right time but for the user it is kind of > odd to not be in the state where he/she was before the screensaver activated. Ungrabbing the pointer and keyboard in the overview can have unexpected side effects, and I don't want to try that. On the other hand, we can reopen the overview when back from away, if consistent state is so important (I don't think so).
Review of attachment 181356 [details] [review]: This is racy, isn't it? See: https://bugzilla.gnome.org/show_bug.cgi?id=637540 For my proposed gnome-screensaver fix.
*** Bug 641635 has been marked as a duplicate of this bug. ***
copying GNOME Target from 641635
(In reply to comment #4) > Review of attachment 181356 [details] [review]: > > This is racy, isn't it? See: > https://bugzilla.gnome.org/show_bug.cgi?id=637540 > > For my proposed gnome-screensaver fix. To elaborate, while gnome-screensaver does sleep 4 seconds, and it's very likely that we pop out of the overview in under 4 seconds, it's still a race; doing it from inside the screensaver also makes sure it works if something invokes gnome-screensaver-command --lock or whatever.
Can we come to some (if suboptimal) decision here ?
Got IRC approval from jon for the screensaver patch, which is in now. We should definitely do something for at least gtk+ grabs for 3.2.
Moving off 3.0 blocker list
Review of attachment 181356 [details] [review]: No longer needed with gnome-screensaver change.
Colin, what did you want to do here for 3.2 ?
I don't see us doing anything for 3.2 here.
This bug should not be considered in the limited context of gnome-screen saver. There are many things that don't work in the activity view which should. Volume control, brightness control, alt-tab, ect.
(In reply to comment #14) > There are many things that don't work in the activity view which should. > Volume control, brightness control, alt-tab, ect. alt-tab is ignored on purpose, for the other keys you mention see bug 643111.
Why is alt-tab ignored on purpose? It's not as though it has some other meaning in that view. This annoys me to no end :) Here you have a view that has no keyboard accessability and you won't let me alt tab out of it? Is there an option to allow it? It still won't work, since alt-tab veiw grabs... But my comment, was not meant to reffer to bug 643111, but to make it clear that the proper solution to this is not, and should not be, through the patching of every possible application that could run into problems with the activities view. The bug lies in the activities view itself, and the activities view alone.
(In reply to comment #16) > Why is alt-tab ignored on purpose? It's not as though it has some other > meaning in that view. What meaning does it have in the overview? If you press Super and then press Alt+Tab, what do you want to happen? > It still won't work, since alt-tab veiw grabs... But > my comment, was not meant to reffer to bug 643111, but to make it clear that > the proper solution to this is not, and should not be, through the patching of > every possible application that could run into problems with the activities > view. The bug lies in the activities view itself, and the activities view > alone. The bug is not in the activities view and the activities view alone. Any application that gets a keyboard grab has the same problems -- even in GNOME 2. The correct solution is to add Grab Overrides, but that won't be ready for quite a while. See: https://fedoraproject.org/wiki/Features/Grab_override
(In reply to comment #17) > (In reply to comment #16) > > Why is alt-tab ignored on purpose? It's not as though it has some other > > meaning in that view. > > What meaning does it have in the overview? If you press Super and then press > Alt+Tab, what do you want to happen? I would personally want alt-tab in the overview to circle through windows much like it does out of the overview. However, out of the overview, alt-tab opens this kind of OSD "list of icons with previews of windows". Inside the overview, I would like it to simply highlight a window, then highlight the next one, etc... Then I could press "enter" or "space" to switch to exit the overview, with that highlighted window coming into focus. That would improve the keyboard navigation of the overview, and allow switching windows in a very similar fashion both in and out of the overview. I'm sure a designer could explain to me how my proposal is wrong though. :)
(In reply to comment #18) <snip> > I'm sure a designer could explain to me how my proposal is wrong though. :) It's wrong because it's the wrong place to discuss this. This bug is about the screensaver not starting when there's a grab in place, this isn't the place to discuss features requests for the overview, or why keyboard grabs don't work in the overview, or the screensaver.
(In reply to comment #19) > (In reply to comment #18) > <snip> > > I'm sure a designer could explain to me how my proposal is wrong though. :) > > It's wrong because it's the wrong place to discuss this. This bug is about the > screensaver not starting when there's a grab in place, this isn't the place to > discuss features requests for the overview, You are absolutely right. For those interested: => https://bugzilla.gnome.org/show_bug.cgi?id=627783#c4 Sorry for the inconvenience, and thank you for the reminder. :)
The screen lock is not implemented in the shell itself, so this is no longer an issue \o/