GNOME Bugzilla – Bug 623429
[ShellGlobal] add SHELL_STAGE_INPUT_MODE_FOCUSED
Last modified: 2010-07-20 19:03:58 UTC
This adds a new ShellStageInputMode where the stage has the keyboard focus but the keyboard is not grabbed. I had started this for the keynav work, but it turns out we want it for the message tray updates in bug 617224 as well.
Created attachment 165141 [details] [review] [ShellGlobal] add SHELL_STAGE_INPUT_MODE_FOCUSED Add SHELL_STAGE_INPUT_MODE_FOCUSED, to move the keyboard focus to the shell without grabbing the keyboard or mouse, and make stage_input_mode into a GObject property so that (among other things), callers can tell when MODE_FOCUSED reverts back to MODE_NORMAL.
Created attachment 165142 [details] [review] fix app menu to not empty out on stage focus This makes the app menu continue to claim that the previously-focused app is currently-focused when the stage has focus. This is definitely the right thing for the a11y keynav case (otherwise there's no way to use the app menu via a11y keynav), but Marina thought Jon had wanted the opposite behavior for chat?
Review of attachment 165141 [details] [review]: The code here looks fine. I'm not completely convinced that this is part of input mode - the input mode I thought of as a question of the reactive area; this seems more like an independent factor; an alternative to some application being focused. But we can see how it works out and adjust as necessary.
Review of attachment 165142 [details] [review]: ::: js/ui/panel.js @@ +482,3 @@ let focusedApp = tracker.focus_app; + if (!focusedApp) + return; If you weren't running nautilus, and you closed the last window from an application, what would happen? Also seems to me to need a comment.
(In reply to comment #3) > I'm not completely convinced that this is part of input mode Originally shell_global_focus_stage() was non-static, and there wasn't a new input mode constant. But focus_stage() wouldn't do anything useful in either FULLSCREEN or NONREACTIVE mode, so adding shell_global_focus_stage() really only resulted in 3+1 states, not 3*2. Also, we need notification of when the focus has been lost, which can mean either having the focus go back to an app, OR having the stage input mode change to NONREACTIVE or FULLSCREEN (because we only ever switch to FULLSCREEN as part of Main.pushModal() in which case clutter focus will be sucked away from wherever we had put it). Mixing focus_stage() into stage-input-mode simplifies the tracking, because we combine both of the above into "if stage-input-mode changes, you lost the focus".
Created attachment 165831 [details] [review] [panel] don't empty out the app menu when the panel itself gets focus this adds a comment and fixes the hack to only happen when the stage itself has been focused, not when there's no focus window for any other reason.
Review of attachment 165831 [details] [review]: ::: js/ui/panel.js @@ +445,3 @@ + return; + } + I'd prefer this to be after the _stopAnimation bits; if we ended up compressing calls to _sync() then we might erroneously continue an animation.
pushed with suggested fix Attachment 165141 [details] pushed as adbf3b1 - [ShellGlobal] add SHELL_STAGE_INPUT_MODE_FOCUSED Attachment 165831 [details] pushed as 539ad81 - [panel] don't empty out the app menu when the panel itself gets focus