Created attachment 139542 [details] kickoff doesn't switches to the first few application categories instantly SUMMARY When I click on the Kickoff menu plasmoid and hover over the first few application categories it doesn't switches to first few categories instantly STEPS TO REPRODUCE 1 move your default plasma panel to the left side of the screen 2 click on the application launcher and hover on the first few application categories, it doesn't switch to the first few categories instantly OBSERVED RESULT kickoff doesn't switches to the first few application categories instantly EXPECTED RESULT kickoff should switch to the first few application categories instantly SOFTWARE/OS VERSIONS Operating System: KDE neon 5.22 KDE Plasma Version: 5.22.1 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION I have attached a screen recording
This behavior also occurs on Plasma 5.22.1 with horizontal panel on bottom. If I move cursor diagonally after opening kickoff, apps from hovered category are not shown. Then I move cursor horizontally on the category initially hovered and its apps are listed in the right side as expected. If I move cursor vertically after opening kickoff, kickoff immediately lists the apps from hovered category in the right side.
I can confirm this behavior when moving the mouse slightly diagonally. I think this is the triangle filter being a bit too eager to think the user wants to move the mouse to the application list on the right.
Category switching definitely feels sluggish and inconsistent.
*** Bug 440009 has been marked as a duplicate of this bug. ***
Yes, this is the triangle filter. If you move your cursor diagonally, the hover event gets eaten if the vector along which you're moving the cursor could end in a clickable item in the main view. This is how triangle filters work and it is something we can't remove because we had approximately five billion complains about how hover used to work, which were resolved by implementing it. However, looking at how other triangle menu filters are implemented, I think what we're missing is a velocity heuristic. Our implementation is purely direction-based; if you move the cursor diagonally very slowly and even stop moving it entirely, the event still gets eaten. Other implementations allow the event through if the speed is low or the cursor stops moving. I think a minimum velocity for the filter would improve the situation.
>Other implementations allow the event through if the speed is low or the cursor stops moving. We do have code in the triangle filter to replay an event if the cursor stops moving, by default for 300ms. See filterTimeOut/m_resetTimer That works in the unit test, but the unit test is rather different to what Kicker has which only has one MouseArea for the whole thing. It does appear to have something slightly off.
Yeah that doesn't seem to be working for me. If I move the cursor diagonally but stop it over a list item, that item never gets selected.
*** Bug 443714 has been marked as a duplicate of this bug. ***
Lets fix the bug with the staying still before we start coming up with new requirements about velocity. I'll rename the bug.
*** Bug 446778 has been marked as a duplicate of this bug. ***
*** Bug 447188 has been marked as a duplicate of this bug. ***
*** Bug 447278 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2100
Raising priority due to number of duplicates.
Git commit f332b03c18f1fa71d4ced051b1289b4cb4513cc1 by Nate Graham, on behalf of Derek Christ. Committed on 03/10/2022 at 07:52. Pushed by ngraham into branch 'master'. apples/kicker: fix timer in triangular mouse filter. The underlying mouse area for kickoff list delegates does not select items when the mouse enters the hovering area, but when the mouse changes its position. Therefore, to change the current selected item, the triangular mouse filter must replay both enter and move events when the triangular fitlering condition is broken. Sometimes, it was possible that the filter only let trough an enter and no following move event, that results in the current hovered item not selected even when the mouse stops its movement completely. The timeout timer that is used to select the hovered item after a time was not at fault, because it is only responsible to do so when the triangular filtering condition is currently upheld, which is not the case in the above mentioned example. M +15 -5 applets/kicker/plugin/trianglemousefilter.cpp https://invent.kde.org/plasma/plasma-workspace/commit/f332b03c18f1fa71d4ced051b1289b4cb4513cc1
Git commit 0661321622cb10e04e621319d7f697d4b97402b0 by Nate Graham, on behalf of Derek Christ. Committed on 03/10/2022 at 08:16. Pushed by ngraham into branch 'Plasma/5.26'. apples/kicker: fix timer in triangular mouse filter. The underlying mouse area for kickoff list delegates does not select items when the mouse enters the hovering area, but when the mouse changes its position. Therefore, to change the current selected item, the triangular mouse filter must replay both enter and move events when the triangular fitlering condition is broken. Sometimes, it was possible that the filter only let trough an enter and no following move event, that results in the current hovered item not selected even when the mouse stops its movement completely. The timeout timer that is used to select the hovered item after a time was not at fault, because it is only responsible to do so when the triangular filtering condition is currently upheld, which is not the case in the above mentioned example. (cherry picked from commit f332b03c18f1fa71d4ced051b1289b4cb4513cc1) M +15 -5 applets/kicker/plugin/trianglemousefilter.cpp https://invent.kde.org/plasma/plasma-workspace/commit/0661321622cb10e04e621319d7f697d4b97402b0
Reopening -- the fix caused other, more serious problems and has been reverted for now. Hopefully someone can come up with a better solution.
That fix was reverted, but I can't reproduce the issue anymore in current git master, so maybe something else fixed it. Can anyone else confirm?
(In reply to Nate Graham from comment #18) > That fix was reverted, but I can't reproduce the issue anymore in current > git master, so maybe something else fixed it. Can anyone else confirm? I can still reproduce the bug on latest master.
Weird, I can't. When I move my cursor diagonally to trigger the triangle filter to not switch categories, it indeed does not switch categories. But then when the cursor steps for a moment, it switches to whatever category the cursor is over. Are you not seeing that?
(In reply to Nate Graham from comment #20) > Weird, I can't. When I move my cursor diagonally to trigger the triangle > filter to not switch categories, it indeed does not switch categories. But > then when the cursor steps for a moment, it switches to whatever category > the cursor is over. > > Are you not seeing that? Yes, in general the timeout of the mouse filter works. But sometimes it happens that a selection is not made, although the timer should have expired. This happens mostly when you make a fast jerky movement diagonally to the upper left. I have described why this happens in more detail in https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2100.
> This happens mostly when you make a fast jerky movement diagonally to the upper left. That seems like a different issue; moving to top left should not trigger the triangle menu logic in the first place, and categories should be highlighted on hover. This works for me FWIW.
(In reply to Nate Graham from comment #22) > > This happens mostly when you make a fast jerky movement diagonally to the upper left. > > That seems like a different issue; moving to top left should not trigger the > triangle menu logic in the first place, and categories should be highlighted > on hover. This works for me FWIW. You're technically correct. We would then need to create a new bug report for this other issue.
Sounds good, let's do that.
(In reply to Nate Graham from comment #24) > Sounds good, let's do that. Done with 462271