The 4.8.x "Kickoff" launcher requires a mouse for Navigation among submenus, and among launchable items, in the horizontal direction. flipScrollView's parent takes care of up/down arrows, but we need to handle key_left, key_right, escape, and any other keys which are necessary for the "GUI-Style" launcher to be used without a mouse. The "classic Style" launcher is unaffected, and it is expected that Applet will be re-written in QML for KDE 4.9. This fix/enhancement will only apply to the 4.8.x series.
It's slightly complicated: "Favorites" works alright, because (1) it doesn't have nested "parents" and "children", AND because "Key_Up" and "Key_Down *are* able depart from the "Favorites" Icon and go into the list of items. From there, User can use "Key_Up" and "Key_Down" to select the desired item, and Enter (or Return) to execute it. "Applications" is broken in two ways: First, the "Key_Down" doesn't exit the row of icons (Favorites - Applications - Comuter -Recently Used - Leave). And, if you could get there (as I did by using the mouse _once_), none of the arrow keys work. Up, Down, Left, and Right are not getting to the widget. "Rcently Used", and "Computer" both work correctly (like "Favorites"). Tthey don't have nested parents and and children, and "Key_Down" / "Key_Up" DO enter the panel, and move among items. In short, only "Applications" is broken. Does anyone disagree?
I forgot to include the tab key - this panel should use focusPolicy of "StrongFocus". It's currently behavior indicates that it has been set (somewhere, perhaps the Parent) to be merely "ClickFocus".
Strangest of all: FlipScrollView::keyPressEvent() re-implelments keyPressEvent, even though it (apparently) will never get called. It tests for Key_Enter, Key_Return, and Key_Escape. But all of these Keys are handled by other Classes- this one DEFINITELY never gets Keyboard Focus.
(In reply to comment #3) > > But all of these Keys are handled by other Classes- this one DEFINITELY > never gets Keyboard Focus. A good guess. Two Other Classes need to set focus on this one when they see a focus-moving key (Up, Down, or Tab). The two Classes are the launcher itself, and also the search widget textarea. The "categories" widget (set of a few icons), should never gain focus at all -- but it might be doing so. In my initial patch, I have to execute TWO keyPressEvent actions (with Tabkey, or a vertical arrow key, or any two of the 3) to activate the area. When the broken class 'All Applications' is being displayed, the there is a round-robin "Ring" of 3 focus States: (A). Focus is on the searchbar text. This State is indicated by a blinking cursor. (B). Focus inside the flipScrollView. This State is indicated by the ability to move right/left and (C). Focus invisible (in the parent) or lost within in the row of category widgets. This State needs to be eliminated. - - - - Depending on the exact cause, the following techniques might solve the problem: #1) If focus enters the "category widgets" view, as a result of right or left arrow, it needs to return focus to the parent immediately. #2) If I am "spending" the original keyPressEvent while establishing focus, then I need to duplicate the keyPressEvent in a second "sendEvent". #3) If the searchbar TextEdit is yielding focus to the Categories Widget, it needs to be recoded (instead yielding focus to the launcher, or directly to the flipScrollView).
The problem is not within "flipscrollview". Rather, the "launcher" Class is keeping focus -- and it offers no keyboard-based way to enter this specialized view. The "FlipScrollView" is somewhat unique, because it's address is stored directly in d->applicationView (and NOT in d->contentArea->currentWidget()). And so *activeVew is set to null, near line 760. The original code (before this patch), only yields focus when (activeView != false) The easy fix is to add an "else" clause to this test: if activeView hasn;'t been set nonzero, we know that it's because the applicationView IS the Selected item in the tab bar (i.e., the bar to where Views are highlighted/chosen). Focus that view, and give it the up/down arrow key. - - - - - I am not able to escape FROM the applicationView so easily- because the Up and Down arrow keys usually need to be kept within the view (changing selected items. To escape from the applicationView, using the Keyboard, you must use the 'tab' key.
In review: https://git.reviewboard.kde.org/r/104422/
Git commit c5a16ec2b64da98991f67dcd991c33abc3888c5c by Rick Stockton. Committed on 29/03/2012 at 02:18. Pushed by stockton into branch 'KDE/4.8'. Kickoff: Use up/down keys to enter 'All Applications' Allow KDE Users to switch into the 'Applications' content area, by using up/down arrow keys. With this ability, it becomes possible to use the Kickoff GUI with only a keyboard (i.e., without a mouse). Related: bug 276932 REVIEW: 104422 M +20 -6 plasma/desktop/applets/kickoff/ui/launcher.cpp http://commits.kde.org/kde-workspace/c5a16ec2b64da98991f67dcd991c33abc3888c5c