Bug 307823

Forgot to say, I'm using Kubuntu 12.04 with KDE SC 4.9.2 from backports PPA.

Confirming this against 4.9.2.

Furthermore, Enter/Return doesn't work anymore when browsing the apps in the "Favorites" kickoff tab - try this:
1. Press Alt+F1 to open Kickoff launcher;
2. In the "Favorites" tab select an app, using up/down arrows;
3. Press Enter --> nothing happens :)

I didn't even notice that :), but yes, I can confirm the problem present.

(In reply to comment #2)
> Confirming this against 4.9.2.
> 
> Furthermore, Enter/Return doesn't work anymore when browsing the apps in the
> "Favorites" kickoff tab - try this
....

Yikes. NONE of the tabs work, except for the "Applications" flipScrollView. (Computer, Recently Used, and Leave tabs). They also fail to execute a 'member' program after you've highlighted it and pressed 'Enter'.

I've modified both 'priority' and 'importance', and attempt fix over the weekend. It may be difficult, because the so-called "controller" doesn't firmly know whether you are focused within the search "view" or the applications lists (i.e., flipScrollView). It only receives the keyboard events, and contains a MESSY sequence of "if" blocks (based on the characters involved) to decide what to do.

I'll comment on a re-design in a couple of days. One possible approach is to "mark" the Up and Down arrow keys by adding different modifiers based on the source of unique child (search text view, flipScrollView, or "search results"). I can also translate to/from variations of the "Tab" key.

But more important: Somehow, the logic now swallows up the 'Enter' key and goes to do something wrong, before deciding that "it" should execute the selected program. That's the first priority; convenient navigation follows afterwards.

i can confirm that the bahaviour of 4.9.2 very confusing. tab sometimes works and sometimes not and sometimes you have to press it multiple times. after this you have to use the arrows to navigate. what was wrong with the 4.9.1 behaviour (simply use the up/down arrow)? For me this was the most productive solution.

It is also a good habit, not to change the behaviour when there is no real(at least for the user perspective) reason to do so. otherwise people are getting annoyed because they have to learn everything again and again.

(In reply to comment #6)
> It is also a good habit, not to change the behaviour when there is no
> real(at least for the user perspective) reason to do so. otherwise people
> are getting annoyed because they have to learn everything again and again.

Well there was a real reason to change behavior. The patch that caused this regression was supposed to fix bug 276932 and bug 297842 but it broke more that it fixed :).

ok. i was not aware of bug 276932.  For me it seems that the problems you tried to fix in Bug 276932 is that the left/right arrow keys are used ambiguously: 

1. navigating the serarch field
2. navigating the kickoff-categories (i.e. applications, favorites, etc)
3. navigating the categories in application menu (level up / down)

The up/down arrow key are used to navigate up/down only. These keys are OK. 

My suggestion: 
1. use left/right arrow only to switch the kickoff categories 
2. use enter and backspace for navigating the application categories. this is consistent with the use of folders in dolphin. 
3. use left/right arrow keys for navigating the search field only if a search term is entered. if the search term gets deleted switch back to kickoff categories

Thank you for all 3 comments (I will verify all in testing).

Now that I have introduced Tab as a functional key, I must support it - together, WITH the arrow keys.

WRT switching kickoff categories: Our categories are more like choosing between split panels, or (closest of all) Konqueror Browser tabs. Konq uses "Ctrl+," and " Ctrl+." for switching between tabs (leftward and rightward respectively). Till, I don't think that Dolphin "Places" are as much a like this as Konqueror Browser "Tabs".  are, and "Enter+Backspace" goes only upwards. Would the Konq scheme be OK?

I have, of course, 3 other ways which could know that you desire a left/right arrow to change the kickoff category, rather than modify a search textArea:

#1 The textArea is empty - both arrows should modify the kickoff category, there is no question that this should work.
#2 You are highlighting the first character, and press "Left" -- should I modify the kickoff category? If so, I will still leave the cursor within the search data entry TextArea, until, you press an "up" or "down" arrow.
#3 You are highlighting the last character, and press "Right" -- same as #2.

Now, within the flipScrollView, should pressing "down" at the bottom of a column, or "up" at the top of a coulmn, relocate you into the search field? Or should you cursur and highlight just stay un-moved (the current behavior), requireing you to know about "Tab" to get in there?

And, any other key combinations to utilize for switching from flipScrollView (applications list, or matching search results) into the "search" text entry textArea?

My thanks in advance, for advice and more WRT the user keys and combinations to use.

(In reply to comment #8)
> The up/down arrow key are used to navigate up/down only. These keys are OK. 
> 
Not really. When the 'Applications' flipScrollView gets focus, you can see that the cursor no longer blinks within the search text. That's good -- it means that the flipScrollView *CAN* execute program items.

But, when going 'down' from the search bar into another tabview (RFU, computer, favorites) the cursor is still blinking in the search text. That's VERY bad, we needed to switch focus. (It's the cause of failure to execute from inside those other tabs.)

Two other nits:
#1: the business about having to press "Tab", or key_down/key_up, twice (rather than once.) focus is getting lost in some other place, either the "launcher" itself or the tab bar. (The first keypress event is getting consumed by one of these two, and it's not generating a new one into the tabview or search bar which should have focus -- until it gets repeated.

#2: I should be able to rise "above the top" of a tabview column, directly into the search text, when someone presses Key_Up while a first-row item is highlighted. And at the bottom, I should be able to "fall through the floor" and end up at the same place (i.e. the search bar.)

Created attachment 74395 [details]
Kickoff - Keyboard Navigation Proposal (WIP)

Here is my proposal of how keyboard navigation in Kickoff should be implemented. It took me some time to make it. I don't know if it is currently possible to implement the scheme I propose since I virtually don't have any knowledge of Qt and Kickoff source code. On the other hand, it has consistent behavior so it should not be hard to implement.

This is a WIP and I probably left something out and didn't cover all use cases. I'll also attach original LibreOffice drawing so that it can be edited.

Created attachment 74396 [details]
Kickoff - Keyboard Navigation Proposal (WIP) (ODG)

Here is LibreOffice Drawing.

@rick: (In reply to comment #9)
> Thank you for all 3 comments (I will verify all in testing).
> 
> Now that I have introduced Tab as a functional key, I must support it -
> together, WITH the arrow keys.
> 
> WRT switching kickoff categories: Our categories are more like choosing
> between split panels, or (closest of all) Konqueror Browser tabs. Konq uses
> "Ctrl+," and " Ctrl+." for switching between tabs (leftward and rightward
> respectively). Till, I don't think that Dolphin "Places" are as much a like
> this as Konqueror Browser "Tabs".  are, and "Enter+Backspace" goes only
> upwards. Would the Konq scheme be OK?
i thought of a folder in dolphin because there is the same way the application categories are displayed on the top (i.e. applications > multimedia). But maybe both key combinations work well because there are multiple interpretations. 

> 
> I have, of course, 3 other ways which could know that you desire a
> left/right arrow to change the kickoff category, rather than modify a search
> textArea:
> 
> #1 The textArea is empty - both arrows should modify the kickoff category,
> there is no question that this should work.
> #2 You are highlighting the first character, and press "Left" -- should I
> modify the kickoff category? If so, I will still leave the cursor within the
> search data entry TextArea, until, you press an "up" or "down" arrow.
> #3 You are highlighting the last character, and press "Right" -- same as #2.
> 
i think the categories are complely switched off as soon as a search term is entered and therefore case #2 and #3 should never occur  (at least this is the behaviour in 4.9.2).  therefore it should be as simple as: 
1. mooving kickoff kategories with left/right if and only if the search field is empty
2. mooving the cursor in the search field with left/right if and only if the search field is not empty

> Now, within the flipScrollView, should pressing "down" at the bottom of a
> column, or "up" at the top of a coulmn, relocate you into the search field?
> Or should you cursur and highlight just stay un-moved (the current
> behavior), requireing you to know about "Tab" to get in there?
>
typing any text should relocate the cursor in the search field. therefore it is possible to enter text at any position in the flipScrollView. therefore it sould be also fine to get back to the top column if pressing down at the bottom colum and vice versa. 

 
> And, any other key combinations to utilize for switching from flipScrollView
> (applications list, or matching search results) into the "search" text entry
> textArea?
> 
any text

> My thanks in advance, for advice and more WRT the user keys and combinations
> to use.

THX too for getting the users involved :)

(In reply to comment #10)
> (In reply to comment #8)
> > The up/down arrow key are used to navigate up/down only. These keys are OK. 
> > 
> Not really. When the 'Applications' flipScrollView gets focus, you can see
> that the cursor no longer blinks within the search text. That's good -- it
> means that the flipScrollView *CAN* execute program items.
> 
> But, when going 'down' from the search bar into another tabview (RFU,
> computer, favorites) the cursor is still blinking in the search text. That's
> VERY bad, we needed to switch focus. (It's the cause of failure to execute
> from inside those other tabs.)
> 
> Two other nits:
> #1: the business about having to press "Tab", or key_down/key_up, twice
> (rather than once.) focus is getting lost in some other place, either the
> "launcher" itself or the tab bar. (The first keypress event is getting
> consumed by one of these two, and it's not generating a new one into the
> tabview or search bar which should have focus -- until it gets repeated.
> 
> #2: I should be able to rise "above the top" of a tabview column, directly
> into the search text, when someone presses Key_Up while a first-row item is
> highlighted. And at the bottom, I should be able to "fall through the floor"
> and end up at the same place (i.e. the search bar.)

i think there is no need to make it that complicated if you dont stay in the "focus" thinking.  as mentioned above. If we have different keys for switching kickoff categories and application categories, we can think of left/right as a key for kickoff categories / search text field cursor and up/down only for navigating the colums. there is no need to switch the focus to the search field or back because you can simply type any text at any state of the kickoff starter. there is also no need to give the kickoff categories any focus because the left/right keys should work all the time.

the same applies to Bojans comments

(In reply to comment #15)
> the same applies to Bojans comments

So if I understood you correctly, your idea basically comes to this:

- left and right arrow keys are always used for switching categories, except when search field has some text.
- Enter and Backspace are used to go into/out of subcategories (as I call them :) ).

That way it's "more practical" and it saves some unneeded key presses?

The problem with this scheme is that it is not very intuitive to unexperienced users and users that are used to classic menu style (think Win 95 style Start menu). In classic menu, you can get wherever you want with only using arrow keys. That's what my proposal is all about. You can get anywhere with *only using arrow keys*. People expect that.

Let's say a user is browsing the Applications category. He figures out that he can move the focus with up and down arrow keys. Nice. Since his fingers are already on arrow key he expects that he can go into subcategory with right arrow key. *Wrong*. It sends him to another category, messing up his work flow, and if he goes back, he probably won't end up in the same subcategory he was in.

Enter and Backspace are used in file managers because you usually have 2D matrix of items where you must use all the arrow keys to navigate. That's why Backspace is needed to send you back or to the parent directory. 

It's not very easy to figure out that Backspace can send you back to parent subcategory.

Think about an average computer user that is maybe using a laptop and that had learned some tricks like keyboard shortcuts and basic keyboard menu navigation to "speed up" his work because touch pad is useless. Experienced user will mostly rely on search and global keyboard shortcuts and will very rarely go to navigate around Kickoff.

In the end, in my proposal, left and right arrow key will in most cases change the category. Only exceptions are when search field is not empty, and therefore categories practically nonexistent, and when Application category is opened.

(In reply to comment #14)
> i think there is no need to make it that complicated if you dont stay in the
> "focus" thinking.  as mentioned above. If we have different keys for
> switching kickoff categories and application categories, we can think of
> left/right as a key for kickoff categories / search text field cursor and
> up/down only for navigating the colums. there is no need to switch the focus
> to the search field or back because you can simply type any text at any
> state of the kickoff starter. there is also no need to give the kickoff
> categories any focus because the left/right keys should work all the time.

Till, I think that you forgot the special problem with the 'Applications' menu (which I'm going to label as the flipScrollView): It's 2D, not just a column. That causes two problems-

(1) You *need* 'Left' and 'Right' to navigate inside. From Application Group, on the "left" of the flipScollView, towards a particular Application (on the right, without any "children").
(2) Without focus in the breadcrumb, or support of 'Key_Left' within the flipScrollView, you can never move towards a "parent" on the left.

I think that a focus change is mandatory for this view (The Application 'flipScrollView'), but none of the others. One of my design mistakes in the 4.8.x "solution" was to move focus in all cases, and we don't need to do that in the other Views. In 9.1 the 'Favorites', 'Computer', 'Recently Used', and 'Logoff' just worked -- without focus. And they should remain UNCHANGED. But flipScrollView needs focus-in and focus-out.

So - I'm with Bojan on a "need" for arrows within the Application view.

But, I don't think that we ever need to 'focus' the the content-switch "tab bar":

(a) SearchView always has focus, unless:
(b) Applications 'flipScrollView' has gained focus via Key_Down, Key_Up, or Key_Tab.

(c) from anywhere within flipScrollView, you can send focus back to the SearchView with Key_Tab.

And I will try to add the following:
(d) Key_Up, while at the TOP ROW of a flipScrollView column, sends focus back to the SearchView.
(e) Key_Down, while at the BOTTOM ROW of a flipscrollview column, sends focus back into the SearchView.
- - - - -

Bojan, I'm inclined to refuse your other enhancements (glow and etc.), because this is scheduled to go away in 4.10 -- and also, because my last "fix attempt" proved to be incompetent. I can program no better than you ;) so let's keep it to an absolute minimum amount of code.

(bugfix, not enhancement.)

(In reply to comment #18)
> But, I don't think that we ever need to 'focus' the the content-switch "tab
> bar":
> 
> (a) SearchView always has focus, unless:
> (b) Applications 'flipScrollView' has gained focus via Key_Down, Key_Up, or
> Key_Tab.
> 
> (c) from anywhere within flipScrollView, you can send focus back to the
> SearchView with Key_Tab.
> 

Yes by the end of my "late night brain(dead)storming" I forgot that categories are hidden when search field is not empty. Combined with left and right arrow key changing category when search field is empty, focus on category tab is never needed. F, A, C, R and L can be combined with Alt so that use case is also redundant.

> Bojan, I'm inclined to refuse your other enhancements (glow and etc.),
> because this is scheduled to go away in 4.10 -- and also, because my last
> "fix attempt" proved to be incompetent. I can program no better than you ;)
> so let's keep it to an absolute minimum amount of code.
> 
> (bugfix, not enhancement.)

Would you consider changing the Esc behavior the way I proposed it? Esc first clears the search field, then closes the Kickoff. Maybe add support for Home and End as proposed?

(In reply to comment #17)
> (In reply to comment #14)
> > i think there is no need to make it that complicated if you dont stay in the
> > "focus" thinking.  as mentioned above. If we have different keys for
> > switching kickoff categories and application categories, we can think of
> > left/right as a key for kickoff categories / search text field cursor and
> > up/down only for navigating the colums. there is no need to switch the focus
> > to the search field or back because you can simply type any text at any
> > state of the kickoff starter. there is also no need to give the kickoff
> > categories any focus because the left/right keys should work all the time.
> 
> Till, I think that you forgot the special problem with the 'Applications'
> menu (which I'm going to label as the flipScrollView): It's 2D, not just a
> column. That causes two problems-
No,  thats why i suggested different shortcuts for swichting flipScrollView and kickoff categories. In this case we dont have this problem. Nevertheless i could unterstand if you dont want to change this behaviour. 

> 
> (1) You *need* 'Left' and 'Right' to navigate inside. From Application
> Group, on the "left" of the flipScollView, towards a particular Application
> (on the right, without any "children").
> (2) Without focus in the breadcrumb, or support of 'Key_Left' within the
> flipScrollView, you can never move towards a "parent" on the left.
> 
> I think that a focus change is mandatory for this view (The Application
> 'flipScrollView'), but none of the others. One of my design mistakes in the
> 4.8.x "solution" was to move focus in all cases, and we don't need to do
> that in the other Views. In 9.1 the 'Favorites', 'Computer', 'Recently
> Used', and 'Logoff' just worked -- without focus. And they should remain
> UNCHANGED. But flipScrollView needs focus-in and focus-out.

(In reply to comment #18)
> So - I'm with Bojan on a "need" for arrows within the Application view.
> 
> But, I don't think that we ever need to 'focus' the the content-switch "tab
> bar":
> 
> (a) SearchView always has focus, unless:
> (b) Applications 'flipScrollView' has gained focus via Key_Down, Key_Up, or
> Key_Tab.
> 
> (c) from anywhere within flipScrollView, you can send focus back to the
> SearchView with Key_Tab.
> 
> And I will try to add the following:
> (d) Key_Up, while at the TOP ROW of a flipScrollView column, sends focus
> back to the SearchView.
> (e) Key_Down, while at the BOTTOM ROW of a flipscrollview column, sends
> focus back into the SearchView.
> - - - - -
> 
> Bojan, I'm inclined to refuse your other enhancements (glow and etc.),
> because this is scheduled to go away in 4.10 -- and also, because my last
> "fix attempt" proved to be incompetent. I can program no better than you ;)
> so let's keep it to an absolute minimum amount of code.
> 
> (bugfix, not enhancement.)

This looks reasonable for me. Its a good compromise without changing the old behaviour to much. (Althoug i still prefer the solution with differen shortcuts ;) )

Yeah, I forgot about Page Up an Page Down. Could be useful with looooong lists.

I've got a version which "kind of" works. It allows you to wander around in the "All Applications" View with arrows in all 4 directions, and execute an application with Key_Enter *or* Key_Return.

Instead of allowing the "All Applications View" to gain focus, it uses a boolean, with getter and setter, for "do I send ALL arrows, and Enter/Return keys into the "All Applications View" ?

Some cleanups are still needed, for Key_Tab versus Key_Up and Key_Down (switching from inside a "View" back to the searchbar, or switching from the searchbar down/up to a View).

It works, mostly -- but keyboard focus can get "trapped" inside the Tab Bar "contentSwitcher", which cannot be escaped without pressing 'Tab'. Here is our choice:

#1: I can make Up/Down do nothing EXCEPT switch between the searchView and the Current content. For this case, I must write code in each type of View (flipScrollView versus  UrlView types) to make translate an Up/Down into a Tab when the person is on the top or bottom item. Bad things about this one: (A) It's a big change in behavior, compared to the current case of simply staying on the current highlighted item when you press an arrow key to go "past" it; (B) you will be REQUIRED to have an empty search text in order to move between Views; (C) Code is awkward and dangerous, adding a lot of new stuff. It would take another week to finish writing and testing. OR:

#2: Stay with the design of 4.8.3 (maybe it was 4.8.2?) - you usually need to use a TAB key to move between views (and the content switcher is still is possible destination of focus). This is pretty much done.
- - - - -
I strongly prefer #2, and I'm willing to write a tiny "help" in EN-US to describe the use of the 'Tab' key in "keyboard-only" mode.

For 4.9.3, making it work more like previous releases is the right answer.  The behavior change in a point release in 4.9.2 is problematic, which (I think) means I like #2.

Thanks, Scott! To summarize- I'd prefer to revise this bug description into: "can't execute items with <Enter> or <Return> in 'Favorites', 'Computer', 'Recently Used', or 'Leave' tab content areas". That is to work like 4.8.x, (x > 2), and 4.y, (y < 7).

It's quite nasty enough to repair even that stuff, WHILE supporting keyboard navigation and execution within Applications "flipScrollView" (which didn't work with 9.0/9.1).

I'd like the basic functionality of executing items first (could be finished in one or two hours). Then, maybe a separate bug for consistent behavior of Up/Down in (A) leaving the search bar; (B) leaving (or even avoiding) the Tab Bar; and (C) leaving a Tab Content area? And/Or a Doco bug, "the use of Key_Tab is not documented in Kickoff "help"?

The original content of this bug was about going to search results from a search.  If I'm reading you correctly, you want to open a new bug for that and change this to cover other easier to fix issues.

I would encourage you to get your can't execute fix in without changing this bug (If you need a bug, file a new one for that and make that one block this one - because that's a good fix) since the part you're leaving for later is exactly what the original bug report is about.  

I don't think that documenting the current behavior is sufficient for this case.  The use of tab to get into the search results is very counter-intuitive and it is also quite difficult to tell when you have the correct focus.

Not so much "easier to fix", but more critical (comments 2-4). I'll continue working on this as a single bug (with both problems included) - but it will take longer. Thanks for coaching me to avoid the division, if possible!

Created attachment 74511 [details]
diff format, not patch format. Proposed Fix 12-Oct-2012.

See also comment #29.

You can now leave the "applications" view by pressing left arrow, when you are already in the leftmost column. And, you can also "escape" from the Applications View by Pressing "Key_Up", while in the top-left corner, or Key_Down, while at the bottom.

Key_up, Key Down, and Key_Tab all function to enter the Applications View -- although, depednign on whether you've entered it before, and where you last left it, it might take two hits.

Created attachment 74513 [details]
patch revision 8 from reviewboard

https://git.reviewboard.kde.org/r/106789/

Simplified: When you LEAVE the "Applications View", you are always put into the "Favorites view". But your cursor is active on the Search Bar - you can enter a search, or use right/left arrows to display another view.

When "Applications View" is displayed, you are not yet inside it. Like the other views, you need to press "Key_Up" to enter and highlight the Bottom-most Application Category, or (more typically) you need to press "Key_Down" to enter and highlight the Top-most category. From there, Key_Right only moves to the right. (At the right edge, it just sits there).

But Key_Left, when you have reached the Leftmost column and Press Key_Left AGAIN, will LEAVE the view (per above, putting you in "Favorites" with active cursor on the search bar). If you are in the top-most row, and additional Key_Up will LEAVE the view. And, if you are in the bottom-most row, Key_Down will leave the View.

Are anyone of you known on review board, and willing to try this out? I will coach on compiling and running it.

(In reply to comment #30)
> Key_up, Key Down, and Key_Tab all function to enter the Applications View --
> although, depednign on whether you've entered it before, and where you last
> left it, it might take two hits.

what does "depending where you last left it" mean? Is there a third state beside "inside application view" and "outside application view / inside search"? Having to press sometimes one and sometimes two times the tab or down key seems counterproductive as i cannot use it "blind". Maybe i just missed a point why this is necessary?!

(In reply to comment #31)
> Created attachment 74513 [details]
> patch revision 8 from reviewboard
> 
> https://git.reviewboard.kde.org/r/106789/
> 
> Simplified: When you LEAVE the "Applications View", you are always put into
> the "Favorites view". But your cursor is active on the Search Bar - you can
> enter a search, or use right/left arrows to display another view.
does this mean pressing "up" goes to the "favorites view" from "application view"? why not simply loose focus on "application view" and go to "search bar / kickoff category swicht mode"? this seems somekind of counterproductive. Example: I use the upp key no navigate to the top most item, but i pressed it one time to much (as a mistake) than i press down again (as i want to correct the last move) and are not at the same place as before.

My comment #30 no longer applies. But comment #31 is the best I can do, for right now. (I kept falling into logic loops while trying to do it "right", it's all very messy.) There are at least 6 States of entry for the Applications Tab: First Entry into the tab in a run of Kickoff (the ApplicationView is freshly initialized; Re-Entry into the Applications View form another View (it instead tries to go back to where you last left it); Entry from the SearchBar, with Search textArea empty and ApplicationView already having been visited at least once, with a location set; and entry from the searchbar, search textArea empty, but no location previously set.

The enforced behavior (pushing you into another Tab first) assures that the ApplicationsView is not continuously visible AND exited via the last character which you typed (Key_Up or Key_Down arrow). "Something" gets reset when you Key_Left or Key_Right back to 'Applications' from another view, making it visible again. Finding what "something" is, and doing the same action to/from the Search Bar and the Applications View, is the subject of new bug https://bugs.kde.org/show_bug.cgi?id=308397. That bug is to avoid the switch into "Favorites" on Key_Up and Key_Down.

In L-to-R orientations, "Favorites" is only one Right-Arrow away from getting back to where you were. But the biggest problems (i.e., no ability to navigate at all, no ability to execute programs from inside certain Views) are already resolved (by either rev 8 or "cleaner" rev 9). So, I want this patch to constitute a platform on which to research that issue. That way, if I can't find "something", THIS fix is already in place for 9.3 (without waiting for the last minute).

For me, it's like eating an elephant - too much to do all at once, and more safely eaten just one meal at a time.

Git commit 8867c8f95133b09bc02ff7f455bd03cc0d8736ce by Rick Stockton.
Committed on 16/10/2012 at 20:30.
Pushed by stockton into branch 'KDE/4.9'.

Fix usage regressions (keyboard-only) in Kickoff-Widget 4.9.2

Bring back Up/Down arrow support for leaving applicationView,
while also keeping the ability to execute applicationView items.
Related: bug 297842
FIXED-IN: 4.9.3

M  +22   -8    plasma/desktop/applets/kickoff/ui/flipscrollview.cpp
M  +1    -0    plasma/desktop/applets/kickoff/ui/flipscrollview.h
M  +89   -44   plasma/desktop/applets/kickoff/ui/launcher.cpp
M  +3    -1    plasma/desktop/applets/kickoff/ui/launcher.h
M  +10   -8    plasma/desktop/applets/kickoff/ui/searchbar.cpp

http://commits.kde.org/kde-workspace/8867c8f95133b09bc02ff7f455bd03cc0d8736ce

And now, on to bug 308397.

Looking forward to 4.9.3. Your work is much appreciated.

Thanks

KDE SC 4.9.3 finally landed for Kubuntu 12.04 so I tested KickOff a little. Works nicely now. There is still some unexpected behavior but as far as this bug is concerned, it's resolved.

Thanks.

THX too -> its in good shape now!