GNOME Bugzilla – Bug 644306
Keyboard navigation of windows in Activities overview
Last modified: 2016-10-13 14:41:36 UTC
Would be nice to be able to: 1. Hit the "super" key for the Activities overview 2. Use the arrow keys to select an open window 3. Hit Enter to leave the overview and bring that window into focus
*** Bug 644320 has been marked as a duplicate of this bug. ***
*** Bug 645914 has been marked as a duplicate of this bug. ***
Agreed. Not being able to do this renders Activities useless if you're not using a mouse.
I notice that if I Ctrl-Alt-Tab to Applications, then I have focus in app table and can navigate in all four directions. This mode is gone when I start to type something and filter apps. Can we have the same for Windows tab too (ie. ability to navigate and enter to select window, until users type something). Also, navigation after C-A-Tab to Applications works, Ctrl-PgDn from Windows to Applications does not, focus is elsewhere. Should be fixed to IMO.
(In reply to comment #4) > Also, navigation after C-A-Tab to Applications works, Ctrl-PgDn from Windows to > Applications does not, focus is elsewhere. Should be fixed to IMO. That's always the case. You can only Ctrl+PgDn for Windows > Applications or Ctrl+PgUp for Windows < Applications. There is no wrap around. If you'd like that behavior then file a new bug as it's unrelated to this one.
(In reply to comment #5) > (In reply to comment #4) > > Also, navigation after C-A-Tab to Applications works, Ctrl-PgDn from Windows to > > Applications does not, focus is elsewhere. Should be fixed to IMO. > > That's always the case. You can only Ctrl+PgDn for Windows > Applications or > Ctrl+PgUp for Windows < Applications. There is no wrap around. If you'd like > that behavior then file a new bug as it's unrelated to this one. I meant navigation after Ctrl-PgDn does not work, not the wrap around. But yes it should be another bug, just noticed "windows" in this bug's description.
*** Bug 651047 has been marked as a duplicate of this bug. ***
If anyone interested, there is an extension https://github.com/tanwald/gnome-shell-extension-arrow-key-window-selector which provides this feature. Though I don't see any reason to not include it by default.
*** Bug 654784 has been marked as a duplicate of this bug. ***
Created attachment 192305 [details] [review] initial draft for introducing overview keyboard support I wrote the extension mentioned in comment 8 and following the requests to transform it into a patch I have created this initial draft. The functionality introduced by this patch is as follows: This patch allows you to select windows in overview mode with the arrow keys of your keyboard. When you are in overview mode and press an arrow key, the most recently focused window will be selected and highlighted/zoomed. As soon as you have navigated to the desired window you can press ENTER for activating the window or DELETE for closing it. Pressing F1-F10 will move the window to the corresponding workspace. Mouse events and other key events will terminate the selection process. Contribution by Tim Cuthbertson: Switch workspaces in overview mode mit PG_UP and PG_DOWN. I have transferred the logic into a separate class called WorkspacesKeyDispatcher. When I needed access to pseudo private members of other classes I wrote getters which might be considered senseless but I didn't want to just ignore the underscores. The logic for selecting windows tries to be as generic as possible and works with existing window-position-strategies. The code is heavily commented and certain decisions are explained. I'm not sure about all decisions and thought it's the right time for opening the discussion.
*** Bug 661718 has been marked as a duplicate of this bug. ***
In addition I would like to suggest to enable a much faster and precise selection of windows with number keys much like this extension does: https://extensions.gnome.org/extension/10/windownavigator/ This would eliminate multiple keystrokes, that would be needed for a selection with the arrow keys.
*** Bug 686522 has been marked as a duplicate of this bug. ***
I think TAB, ALT-TAB and ALT-SHIFT-TAB should should work as well. Just many people have these shortcuts hardwired in theirs brains. It would be only consistent if they also work in overview. As for cursor keys: I think up/down should change workspace, left/right should change window. When using mod4 to switch to overview and cursor keys to change windows/workspaces, both hands are involved at pretty easy to find locations on the keyboard. Should be very efficient. But i'm fine with everything else as a default long as i can change it :-) eTM
+1 This should be really one of the first things to be fixed. It is simply unnatural that keyboard selection doesn't work.
How much more discussion is required to impliment this? I think arrow keys would feel natural here, they compliment C-A-UpDown to scroll the workspaces. Paul Neulinger, can your extension be modded to work with 3.4 ?
The patch submitted in comment 10 no longer applies. Paul - if you'd like to update it, I'll try and make sure that someone reviews it. Otherwise, it would be great if someone wants to pick up this work.
It would certainly help to have bug 665310 fixed before to avoid duplicating efforts for the focus/hover border rendering.
bug 665310 is fixed now, as far as is looks.
*** Bug 693265 has been marked as a duplicate of this bug. ***
Created attachment 239307 [details] [review] keyboard navigation in overview Hi, I took the liberty to rebase the previous patch on master. I hope I didn't hurt anybody ;) I also removed the lightbox animations and used the stock window highlight since it's available now (#665310). As far as I can tell it works quite well, but I noticed some issues in some cases. I have to work that out.
Created attachment 239309 [details] [review] workspace: Implement simple keyboard navigation in the overview And here's a much simpler patch that uses our existing keynav infrastructure. It's not complete, but it's a lot more workable for what it does. I don't exactly know what keynav should be -- should you be able to keynav to all elements (search, windows, dash, panel??) with just the arrow keys? This is something to talk to the a11y people and the designers about.
I tried the patch. One thing I find strange is that you need to use the down arrow to select the first window (top left), then you can navigate. I also can't navigate in windows on my secondary screen. What would it take to handle secondary screens ? Also, it seems that it makes the shell crash when dragging a windows with the mouse: (gnome-shell:13153): St-ERROR **: st_widget_get_theme_node called on the widget [0x7f9008026970 StWidget] which is not in the stage.
(In reply to comment #23) > I tried the patch. One thing I find strange is that you need to use the down > arrow to select the first window (top left), then you can navigate. I also > can't navigate in windows on my secondary screen. Yeah, it's not perfect. It's something I whipped up very quickly. It would require a considerable effort to do this better for 3.10, and I plan to pick that up. > What would it take to handle secondary screens ? Again, it depends how keynav is designed -- can you arrow to the workspace thumbnails, dash, and search? > Also, it seems that it makes the shell crash when dragging a windows with the > mouse: > > (gnome-shell:13153): St-ERROR **: st_widget_get_theme_node called on the widget > [0x7f9008026970 StWidget] which is not in the stage. Sigh. Known DND bug. I'll see if I can fix that soon.
(In reply to comment #24) > (In reply to comment #23) > > I tried the patch. One thing I find strange is that you need to use the down > > arrow to select the first window (top left), then you can navigate. I also > > can't navigate in windows on my secondary screen. > > Yeah, it's not perfect. It's something I whipped up very quickly. It would > require a considerable effort to do this better for 3.10, and I plan to pick > that up. > Should we land this for now, and then work on improving it ?
(In reply to comment #25) > Should we land this for now, and then work on improving it ? Considering it crashes when you try to drag windows, no. I can see about fixing that short-term, though.
*** Bug 704011 has been marked as a duplicate of this bug. ***
Created attachment 258968 [details] [review] trivial: st-widget: Remove super old 'stylable' property I don't think we ever used this, even way back in 3.0...
Created attachment 258969 [details] [review] trivial: st-widget: Fix the signedness of boolean fields The standard old kludge with gboolean being signed, not unsigned. Encountered while printing the values for debugging.
Created attachment 258970 [details] [review] st-widget: Sort actors by distance from the focused actor Sorting actors by the distance in the axis of movement first and against the axis otherwise means that if we have a situation like: A F B where "F" is the focused actor, and it slightly overlaps with B vertically, then we'll choose "B" to go left, rather than "A", which is most likely what the user intended. This is especially apparent in the overview where slight window size differences mean we might not get an exact grid shape.
Created attachment 258971 [details] [review] workspace: Implement key navigation on the workspaces page Simply use St's existing key navigation system by making all the window clones StWidgets, and making the WorkspacesView a focus group. Since the workspace view is effectively "fake", we need to add a focus delegator so that when key focus is assigned to the fake workspaces page, we can keynav inside it properly.
Created attachment 258972 [details] [review] workspace: Grab the key focus when hovering over a window This is simply an experiment. I'm not sure I like the result, but it was worth trying out regardless.
Created attachment 258973 [details] [review] viewSelector: Give the active page key focus when it is shown Rather than implement special focus policies like only allowing keynav when pressing down, simply give the active page key focus when entering the overview. This may break stuff, as it's somewhat of a tricky patch to get right. Testing this one would be super appreciated.
Review of attachment 258968 [details] [review]: OK.
Review of attachment 258969 [details] [review]: We have this in other places as well: git grep gboolean | grep ": 1" src/shell-app.c: gboolean window_sort_stale : 1; src/st/st-adjustment.c: gboolean is_constructing : 1; src/st/st-scroll-view.c: gboolean row_size_set : 1; src/st/st-scroll-view.c: gboolean column_size_set : 1; src/st/st-widget.c: gboolean is_stylable : 1; src/st/st-widget.c: gboolean is_style_dirty : 1; src/st/st-widget.c: gboolean draw_bg_color : 1; src/st/st-widget.c: gboolean draw_border_internal : 1; src/st/st-widget.c: gboolean track_hover : 1; src/st/st-widget.c: gboolean hover : 1; src/st/st-widget.c: gboolean can_focus : 1;
Attachment 258968 [details] pushed as 5c0ee02 - trivial: st-widget: Remove super old 'stylable' property
Review of attachment 258970 [details] [review]: OK. ::: src/st/st-widget.c @@ +1887,3 @@ + dy = ay - by; + + return sqrt (dx*dx + dy*dy); Nitpick sqrt is not really needed for that purpose but OTOH it is more correct that way.
Review of attachment 258971 [details] [review]: ::: js/ui/workspace.js @@ +90,2 @@ this.actor.connect('destroy', Lang.bind(this, this._onDestroy)); + this.actor.connect('key-press-event', Lang.bind(this, this._onKeyRelease)); This makes no sense. You connect to key-press but call the callback onnKeyRelease ... wrong event?
(In reply to comment #37) > Nitpick sqrt is not really needed for that purpose but OTOH it is more correct > that way. Oh, right, since we're simply comparing to sort, we can simply compute the square of the hypotenuse, and it still sorts correctly. (In reply to comment #38) > This makes no sense. > > You connect to key-press but call the callback onnKeyRelease ... wrong event? I think it was key-release-event initially but I just forgot to change the callback name. I don't really care which event it is, but yeah, it should be consistent. We also activate search results on key press, so I think I'll keep the existing event name and rename the callback.
Created attachment 259045 [details] [review] st-widget: Sort actors by distance from the focused actor Sorting actors by the distance in the axis of movement first and against the axis otherwise means that if we have a situation like: A F B where "F" is the focused actor, and it slightly overlaps with B vertically, then we'll choose "B" to go left, rather than "A", which is most likely what the user intended. This is especially apparent in the overview where slight window size differences mean we might not get an exact grid shape.
Created attachment 259046 [details] [review] workspace: Implement key navigation on the workspaces page Simply use St's existing key navigation system by making all the window clones StWidgets, and making the WorkspacesView a focus group. Since the workspace view is effectively "fake", we need to add a focus delegator so that when key focus is assigned to the fake workspaces page, we can keynav inside it properly.
Review of attachment 259045 [details] [review]: OK.
Created attachment 260478 [details] [review] viewSelector: Give the active page key focus when it is shown Rather than implement special focus policies like only allowing keynav when pressing down, simply give the active page key focus when entering the overview. This may break stuff, as it's somewhat of a tricky patch to get right. Testing this one would be super appreciated. Rebasing patch.
Attachment 258972 [details] pushed as aeb9f57 - workspace: Grab the key focus when hovering over a window Attachment 259045 [details] pushed as a7aba1d - st-widget: Sort actors by distance from the focused actor Attachment 259046 [details] pushed as 47a2075 - workspace: Implement key navigation on the workspaces page Attachment 260478 [details] pushed as ec2bb03 - viewSelector: Give the active page key focus when it is shown
Ugh. I've been trying these patches before starting reviewing them, and they didn't work great in testing: - tab/shift-tab order in workspace page is occasionally reversed - app view keynav is broken if not explicitly focused with ctrl-alt-tab - keynav can get stuck completely (hit <super>a twice and neither arrows nor tab will navigate in windows) It would have been nice to address those issues before pushing without review, but let's at least fix them after the face. Reopening.
(In reply to comment #45) > It would have been nice to address those issues before pushing without review, > but let's at least fix them after the face. Reopening. So, just curious, for next time, how could I convince you to review these patches?
(In reply to comment #46) > So, just curious, for next time, how could I convince you to review these > patches? I'm sorry that I have other stuff on my plate as well, but it was on my list (and since yesterday, towards the top) - it's not a trivial patch set that I'm confident reviewing "blindly" or quickly in between other stuff. However I had started to test the set locally earlier today (minus the first one which didn't apply cleanly and didn't look overly important), in order to start the review. So yeah, shitty timing.
I think this is the right time: I would a real "Thank you" the everyone who has and is working on this feature. It would be absolutely greate to see this in GNOME 3.12 working :-)
Comment on attachment 260478 [details] [review] viewSelector: Give the active page key focus when it is shown The problems noted in comment #45 were mostly due to attachment 260478 [details] [review] which was reverted for the release; any plans on picking this up, or should we just close the bug now?
Me, you mean? I'm not picking this back up. Feel free to make it work properly, but please don't close it WONTFIX.
No, I would it close as fixed - the problematic patch was not supposed to add any functionality, so with the cleanup reverted it works well enough.
Well, the bug is that only down starts keynav mode, not left/right/up. One other thing you can try is focusing the active window -- that might be good enough.
(In reply to comment #52) > Well, the bug is that only down starts keynav mode, not left/right/up. Right works here iff there is a window to the right of the focused window.