*** Bug 611978 has been marked as a duplicate of this bug. ***

*** Bug 613512 has been marked as a duplicate of this bug. ***

Following search in the overview, the down keyboard arrow now moves to the next app which is to the right (left over from vertical app results).
It is more intuitive that it goes to the first of the next section (preferences, devices, recent docs) and right goes to the next app.
Also, apps could scroll as you do this if there are more than a few.

*** Bug 627955 has been marked as a duplicate of this bug. ***

Created attachment 181833 [details] [review]
ctrlAltTab: misc improvements

Fix the "panel" icon to be symbolic. Make the overview parts only show
up when in the overview, and the non-overview parts (eg, the Desktop
window, if there is one) only show up when not in the overview. Sort
the different items consistently with their locations on the screen.

Created attachment 181834 [details] [review]
St: add a popup-menu signal to StWidget

Add a popup-menu signal to StWidget, and emit it if the user types the
Menu key or Shift+F10 while the widget is focused.

Created attachment 181835 [details] [review]
overview, appDisplay: add Dash to Ctrl-Alt-Tab

Add the dash to Ctrl-Alt-Tab, add appropriate :focus CSS, and connect
to the popup-menu signal on dash icons.

proper popup-menu keynav depends on bug 641253

Created attachment 181836 [details] [review]
viewSelector: add Applications pane and search entry to Ctrl-Alt-Tab

Add Ctrl-Alt-Tab support to ViewTab, and fix the Applications pane to
scroll to track the keyboard focus.

The Windows pane can be switched to, but navigation within the pane is
not yet implemented.

This doesn't change the way search result keynav works, which is discussed in bug 640779

*** Bug 587071 has been marked as a duplicate of this bug. ***

I hope I'll not break my fingers with Ctrl+Alt+Tab keystroke :)

See the simplicity: Alt+F1, Arrow up, Arrow Up, Arrow Up, Arrow Right, Arrow Down, Enter - and the DevHelp is running (not having CMake installed I save the Arrow Down). No hard keystroke in there. Would I be able to learn such simple way of running devhelp from gnome-shell too? I do not want to break my left hand on my daily job, you know.

Note I do not count search ability as one of them, though it may save me from few Arrow presses, in a cost of writing (part of) an application name.

(In reply to comment #11)
> I hope I'll not break my fingers with Ctrl+Alt+Tab keystroke :)
> 
> See the simplicity: Alt+F1, Arrow up, Arrow Up, Arrow Up, Arrow Right, Arrow
> Down, Enter - and the DevHelp is running (not having CMake installed I save the
> Arrow Down). No hard keystroke in there. Would I be able to learn such simple
> way of running devhelp from gnome-shell too? I do not want to break my left
> hand on my daily job, you know.
> 
> Note I do not count search ability as one of them, though it may save me from
> few Arrow presses, in a cost of writing (part of) an application name.

why don't you consider searching a legitimate way to get to applications?

Review of attachment 181833 [details] [review]:

Look fine to commit, as far as I can tell. Few things need commenting.

::: js/ui/ctrlAltTab.js
@@ +70,3 @@
+    },
+
+    _sortItems: function(a, b) {

Maybe a comment here about why we sort paying attention to the items X position - it's not immediately obvious to me.

::: js/ui/panel.js
@@ +1006,3 @@
+
+        Main.ctrlAltTabManager.addGroup(this.actor, _("Panel"), 'start-here',
+                                        { sortGroup: CtrlAltTab.SortGroup.TOP });

Maybe a comment about why we are using start-here - it's not at all obvious (because it has a symbolic version and looks right?) - I mean, start-here - that's the thing that we had on the Red Hat 8/GNOME-2.0 desktop as a replacement for Computer, I think?

Review of attachment 181834 [details] [review]:

Looks fine

(In reply to comment #13)
> Maybe a comment here about why we sort paying attention to the items X position
> - it's not immediately obvious to me.

It makes more sense when there's more stuff added to it; it keeps the dialog in the same visual order as the screen. (The "complete" overview tab order is: Panel, Dash, Windows, Applications, Search, Message Tray)

> Maybe a comment about why we are using start-here - it's not at all obvious
> (because it has a symbolic version and looks right?)

Actually, it has a symbolic version and looks *wrong* (and is now overridden with a non-symbolic Fedora logo in Rawhide...) See bug 641303 comment 2.

Review of attachment 181835 [details] [review]:

Looks fine

::: js/ui/overview.js
@@ +197,3 @@
         this.dash.actor.add_constraint(this.viewSelector.constrainY);
         this.dash.actor.add_constraint(this.viewSelector.constrainHeight);
+        Main.ctrlAltTabManager.addGroup(this.dash.actor, _("Dash"), 'user-bookmarks');

Hmm, do we want Dash as a end-user name? I don't have an alternate for it though.

(In reply to comment #16)
> Hmm, do we want Dash as a end-user name?

Jon said that's its official name.

Hm... probably should have a translator comment

Review of attachment 181836 [details] [review]:

Can't say I like the feel of the result much - having primary keynav around the overview be on such an awkward key combination as Control-Alt-Tab. The overview is basically an "application" in itself, not a combination of special system places. Maybe it is (as in the names in this patch) just an "a11y" thing, but presumably if you are keynaving around continually, comfortable keynav matters to you.

But that being said, it works, it increases the total keynavigability, and I don't really have better suggestions, especially suggestion that don't get in the way of the primary use of the keyboard for search and search result navigation, so I think this is a step in the right direction, and if someone actually designs overview keynav more comprehensively at some point we can always change.

::: js/ui/appDisplay.js
@@ +79,3 @@
+    _ensureIconVisible: function(icon) {
+        let adjustment = this.actor.vscroll.adjustment;
+        let [value, lower, upper, stepIncrement, pageIncrement, pageSize] = adjustment.get_values();

Hmm, with the fade involvement, might have been easier to add something to StScrollView (st_scroll_view_ensure_actor_visible(), perhaps), but OK this way

@@ +150,3 @@
+        // our real contents
+        this._focusDummy = new St.Bin({ can_focus: true });
+        this.actor.add(this._focusDummy);

ouch!

(In reply to comment #18)
> Review of attachment 181836 [details] [review]:
> 
> Can't say I like the feel of the result much - having primary keynav around the
> overview be on such an awkward key combination as Control-Alt-Tab. The overview
> is basically an "application" in itself, not a combination of special system
> places.

It just seemed that if we had the overview behaving as a single "focus group", then navigation (especially *blind* navigation) would get very confusing. Eg, when navigating around the application list or window picker, rather than stopping at the edge, you'd fall out into the dock / viewSelector tabs / search entry.

But we can add additional keybindings too.

Attachment 181833 [details] pushed as af4fcc8 - ctrlAltTab: misc improvements
Attachment 181834 [details] pushed as fe16f2b - St: add a popup-menu signal to StWidget
Attachment 181835 [details] pushed as 7aa326a - overview, appDisplay: add Dash to Ctrl-Alt-Tab
Attachment 181836 [details] pushed as 0cccf1d - viewSelector: add Applications pane and search entry to Ctrl-Alt-Tab