After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 644306 - Keyboard navigation of windows in Activities overview
Keyboard navigation of windows in Activities overview
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: overview
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 644320 645914 651047 654784 661718 686522 693265 704011 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-03-09 13:36 UTC by Steven Garrity
Modified: 2016-10-13 14:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
initial draft for introducing overview keyboard support (24.12 KB, patch)
2011-07-20 13:45 UTC, Paul Neulinger
none Details | Review
keyboard navigation in overview (17.88 KB, patch)
2013-03-19 21:15 UTC, Jean-Philippe Braun
none Details | Review
workspace: Implement simple keyboard navigation in the overview (5.11 KB, patch)
2013-03-19 21:53 UTC, Jasper St. Pierre (not reading bugmail)
none Details | Review
trivial: st-widget: Remove super old 'stylable' property (3.16 KB, patch)
2013-11-05 02:11 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
trivial: st-widget: Fix the signedness of boolean fields (1.12 KB, patch)
2013-11-05 02:11 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
st-widget: Sort actors by distance from the focused actor (6.25 KB, patch)
2013-11-05 02:11 UTC, Jasper St. Pierre (not reading bugmail)
accepted-commit_now Details | Review
workspace: Implement key navigation on the workspaces page (5.49 KB, patch)
2013-11-05 02:11 UTC, Jasper St. Pierre (not reading bugmail)
reviewed Details | Review
workspace: Grab the key focus when hovering over a window (1.28 KB, patch)
2013-11-05 02:11 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
viewSelector: Give the active page key focus when it is shown (2.50 KB, patch)
2013-11-05 02:11 UTC, Jasper St. Pierre (not reading bugmail)
none Details | Review
st-widget: Sort actors by distance from the focused actor (6.31 KB, patch)
2013-11-05 21:28 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
workspace: Implement key navigation on the workspaces page (5.48 KB, patch)
2013-11-05 21:28 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
viewSelector: Give the active page key focus when it is shown (2.12 KB, patch)
2013-11-21 17:54 UTC, Jasper St. Pierre (not reading bugmail)
needs-work Details | Review

Description Steven Garrity 2011-03-09 13:36:20 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
Comment 1 Dan Winship 2011-03-09 16:27:35 UTC
*** Bug 644320 has been marked as a duplicate of this bug. ***
Comment 2 Dan Winship 2011-03-28 12:07:38 UTC
*** Bug 645914 has been marked as a duplicate of this bug. ***
Comment 3 David Prieto 2011-04-24 01:49:32 UTC
Agreed. Not being able to do this renders Activities useless if you're not using a mouse.
Comment 4 Nguyen Thai Ngoc Duy 2011-05-24 16:27:03 UTC
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.
Comment 5 Rui Matos 2011-05-24 16:57:25 UTC
(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.
Comment 6 Nguyen Thai Ngoc Duy 2011-05-24 17:01:49 UTC
(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.
Comment 7 Florian Müllner 2011-05-25 10:53:39 UTC
*** Bug 651047 has been marked as a duplicate of this bug. ***
Comment 8 Aleksandra Bookwar 2011-07-13 01:19:30 UTC
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.
Comment 9 Florian Müllner 2011-07-17 15:01:02 UTC
*** Bug 654784 has been marked as a duplicate of this bug. ***
Comment 10 Paul Neulinger 2011-07-20 13:45:14 UTC
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.
Comment 11 Florian Müllner 2011-10-13 22:58:45 UTC
*** Bug 661718 has been marked as a duplicate of this bug. ***
Comment 12 Jochen Breuer 2012-04-11 14:46:05 UTC
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.
Comment 13 Rui Matos 2012-10-20 16:31:34 UTC
*** Bug 686522 has been marked as a duplicate of this bug. ***
Comment 14 Jürgen Mangler 2012-10-24 22:04:10 UTC
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
Comment 15 Peter 2012-10-25 11:05:37 UTC
+1

This should be really one of the first things to be fixed. It is simply unnatural that keyboard selection doesn't work.
Comment 16 Pat Emblen 2012-11-03 22:17:43 UTC
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 ?
Comment 17 Allan Day 2012-11-05 15:55:09 UTC
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.
Comment 18 Stéphane Démurget 2012-11-17 15:22:31 UTC
It would certainly help to have bug 665310 fixed before to avoid duplicating efforts for the focus/hover border rendering.
Comment 19 Peter 2012-11-22 10:25:09 UTC
bug 665310 is fixed now, as far as is looks.
Comment 20 Florian Müllner 2013-02-06 16:22:55 UTC
*** Bug 693265 has been marked as a duplicate of this bug. ***
Comment 21 Jean-Philippe Braun 2013-03-19 21:15:02 UTC
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.
Comment 22 Jasper St. Pierre (not reading bugmail) 2013-03-19 21:53:04 UTC
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.
Comment 23 Jean-Philippe Braun 2013-03-22 12:16:26 UTC
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.
Comment 24 Jasper St. Pierre (not reading bugmail) 2013-03-22 17:07:42 UTC
(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.
Comment 25 Matthias Clasen 2013-04-10 12:35:35 UTC
(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 ?
Comment 26 Jasper St. Pierre (not reading bugmail) 2013-04-10 15:31:35 UTC
(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.
Comment 27 Jasper St. Pierre (not reading bugmail) 2013-07-11 15:21:23 UTC
*** Bug 704011 has been marked as a duplicate of this bug. ***
Comment 28 Jasper St. Pierre (not reading bugmail) 2013-11-05 02:11:07 UTC
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...
Comment 29 Jasper St. Pierre (not reading bugmail) 2013-11-05 02:11:16 UTC
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.
Comment 30 Jasper St. Pierre (not reading bugmail) 2013-11-05 02:11:22 UTC
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.
Comment 31 Jasper St. Pierre (not reading bugmail) 2013-11-05 02:11:30 UTC
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.
Comment 32 Jasper St. Pierre (not reading bugmail) 2013-11-05 02:11:38 UTC
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.
Comment 33 Jasper St. Pierre (not reading bugmail) 2013-11-05 02:11:46 UTC
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.
Comment 34 drago01 2013-11-05 11:06:16 UTC
Review of attachment 258968 [details] [review]:

OK.
Comment 35 drago01 2013-11-05 11:07:42 UTC
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;
Comment 36 Jasper St. Pierre (not reading bugmail) 2013-11-05 14:12:42 UTC
Attachment 258968 [details] pushed as 5c0ee02 - trivial: st-widget: Remove super old 'stylable' property
Comment 37 drago01 2013-11-05 18:51:29 UTC
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.
Comment 38 drago01 2013-11-05 18:54:37 UTC
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?
Comment 39 Jasper St. Pierre (not reading bugmail) 2013-11-05 21:26:16 UTC
(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.
Comment 40 Jasper St. Pierre (not reading bugmail) 2013-11-05 21:28:08 UTC
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.
Comment 41 Jasper St. Pierre (not reading bugmail) 2013-11-05 21:28:12 UTC
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.
Comment 42 drago01 2013-11-05 22:07:10 UTC
Review of attachment 259045 [details] [review]:

OK.
Comment 43 Jasper St. Pierre (not reading bugmail) 2013-11-21 17:54:35 UTC
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.
Comment 44 Jasper St. Pierre (not reading bugmail) 2013-12-04 18:43:38 UTC
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
Comment 45 Florian Müllner 2013-12-04 18:55:12 UTC
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.
Comment 46 Jasper St. Pierre (not reading bugmail) 2013-12-04 19:02:42 UTC
(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?
Comment 47 Florian Müllner 2013-12-04 19:21:10 UTC
(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.
Comment 48 Peter 2013-12-05 17:19:42 UTC
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 49 Florian Müllner 2014-11-07 19:19:57 UTC
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?
Comment 50 Jasper St. Pierre (not reading bugmail) 2014-11-07 21:31:01 UTC
Me, you mean? I'm not picking this back up. Feel free to make it work properly, but please don't close it WONTFIX.
Comment 51 Florian Müllner 2014-11-07 21:44:46 UTC
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.
Comment 52 Jasper St. Pierre (not reading bugmail) 2014-11-07 22:18:50 UTC
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.
Comment 53 Florian Müllner 2014-11-07 22:46:32 UTC
(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.