307823 solves Kickoff Up/Down navigation from "inside" the "Applications View" by moving the GUI to the next view Left. (In L to R layout, that is the "Favorites" View.) It would be less disruptive, if possible, to simply move Keyboard Focus back into the Search bar, without actually changing the visible View within the content area. Leave it as Applications View, but allow characters to enter a Search Text, and Key_Left/Key_Right to actually perform change of the selected View. Reproducible: Always Steps to Reproduce: 1. Select the 'Applications Tab', and move to the Top row (i10n of "Administration"). 2. With this item selected (shown in a blue-lined box), press the arrow key (Qt::Key_Up) OR: 1. Select the Applications Tab, and, using the "Down" arrow Key, move down to the Bottom category/Item (normally, this is i10n of "Personal Files"). 2. Press Down arrow again. Actual Results: Your "View" is flipped over to "Favorites". Expected Results: You should be located on the "search bar", with "Applications" still shown in the main content area. Low priority, because (IMO) Users without a mouse should be using the "Classic" launcher anyway. The easy workaround is: Just press Right Arrow (Qt::Key_Right), and you're exactly where you want to be.
Assigning to myself, with the hope that I can do this in time for 9.3. The far more important bug 307823, which solves the major usability breakage while creating this "small wierdness", needs to be resolved first -- I can't touch this area again before that code is stable.
I have created a version of KickOff which will keep the applicationView (i.e., &flipScrollView) visible when an "up" or "down" arrow goes is treated as "re-focus the searchBar", and avoid sending Left/Right into the applicationView. This version LITERALLY changes focus between the views, when the applicationView isVisible. (That's a new change, in comparision to the the resolution of bug 307823, which does not change focus -- it stayed with the original design of explicitly routing arrow keys from "launcher" into the two possible destinations (i.e., applicationView and contentSwitcher). The first problem is: That's a fundamental re-design of keyboard focus, very dangerous. (A large testing effort would be required, there are _AT LEAST_ 9 cases of focus entry/exit to verify.) The 2nd, bigger problem is: The only way to see that your keyboard events are currently going directly into applicationView (i.e., rather than the carefully directed sequence of alternatives within 'lancher') is the fact that searchBar no longer contains the blinking cursor. In comparision to flipping you over to Favorites, this is (IMO) VASTLY too "subtle" a hint. And of course, it still requires a keypress to switch back "into" applicationView anyway. The only difference being that it's now Key_Tab, or Key_Down, or Key_Up, instead of Key_Right (or, in R-to-L layout, Key_Left). This is not sufficiently visual. I've tried to introduce a complete repaint of applicationView (i.e., flipScrollView) with 'Inactive' palette when focus is not inside applicationView, but I'm unable to create code which works. (Ivan, a VASTLY better KDE coder than I, apparently tried to do the same thing with transparency - and he also seems to have given up on the "feature" as well, leaving only a small, uncalled subroutine behind.)
It may be better to focus this work into 4.10 and revert 4.9 back to what it was in 4.9.1.
Hi, Scott -- thanks for the quick come-back :)) I think that 4.9 should absolutely not going back to the 4.9.0/4.9.1 version, because they had bug 297842 (no way to go "back", up to searchBar without a mouse). Tons of votes, and a really major problem. Now, as you know, 4.10 is planned with a total replacement, using QML for the UI. I plan to test the QML version, soon, with Bojan's "keyboard keys need to be implemented with the following scheme" attachment for bug 307823: https://bugs.kde.org/attachment.cgi?id=74396 Do you see a big benefit in changing the applicationView (more transparent, or dimmer, or some other widget palette change) when the L+R arrows are going to change views, rather than flipping you over to 'favorites'? If so, I'll need some help coding that -- I can't get my (&,*, this., parent *) stuff straight in attempting to write a slot which will change the FlipScollView's palette, callable from inside routines where I can't change the signature to include a ref. Yes, in spite of one huge accomplishment for Qt5, I'm newby at C++ and Qt.
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug is already resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham