I'm using Arch linux with vanilla KDE on it and I have noticed this for quite a bit. When browsing the launcher's categories like "Internet", "Graphics", "Game", "Settings" etc. there's a general feel that triggering the sub-menus is not instantly responsive all the time. To test it it's enough to fire a launcher with a Win key and keep browsing the main categories with a mouse. You'll notice that there would be times when hovering a cursor over a certain Category (e.g. going from "Settings" to "Development") won't ignite anything, unless you move a mouse again for another pixel or so. I first thought it was because categories were heavily populated, so there was a delay of displaying the submenus. But that's not the case. Same can be seen even with only Plasma package installed with very few programs. Operating System: Arch Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.8 Kernel Version: 6.1.3-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 5500 XT Manufacturer: Micro-Star International Co., Ltd Product Name: MS-7C02 System Version: 1.0
I've tried to fix it once but the fix introduced more problems than solved: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/929 Now I have not much ideas how it can be fixed properly without handling a lot of cases manually which is obviously not a great way in terms of maintainability.
Generally if you move the mouse towards the right, the menu does not switch immediately on purpose because in that action you are most likely moving towards the app list/grid on the right-hand-side to select an app, and switching categories would be annoying. Moving up and down in a straight line should be perfectly fast.
Well, I'm no programmer, I can hack a bit, but that's where my 'expertise' ends. So sadly cannot help you on this one in that sense. I'm not sure where the problem is in this. Speaking as the user of KDE, this does break the fluidity and how someone would expect it to work. It works at least, there are no residuals or false hovers, but sluggishness is obvious and should be optimized somehow. (In reply to Artem Grinev from comment #1) > I've tried to fix it once but the fix introduced more problems than solved: > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/929 > > Now I have not much ideas how it can be fixed properly without handling a > lot of cases manually which is obviously not a great way in terms of > maintainability.
(In reply to Bharadwaj Raju from comment #2) > Generally if you move the mouse towards the right, the menu does not switch > immediately on purpose because in that action you are most likely moving > towards the app list/grid on the right-hand-side to select an app, and > switching categories would be annoying. > > Moving up and down in a straight line should be perfectly fast. I understand what you are saying. I agree there should be a certain 'threshold' when user is moving diagonally towards the app list and that's fine. However, how 'straight' that line is for the menu is not good, non-response is obvious when you are browsing the menus for a bit longer. You can only move in a straight line with a cursor, cannot expect a mouse to do so.
To be clear, it doesn't need to be perfectly straight — moving even at a ~10° angle to the right is still "straight" enough to be immediate. You can visualize it as a triangle with one point at your cursor and the other two at the top-left and bottom-left of the app list/grid. As long as you're not moving your mouse such that you stay inside that triangle, it will switch categories. I don't think that can be adjusted without making the other action (going from category to apps) worse. I think it would be a better solution to fix the issue where *sometimes* holding your cursor over an item doesn't switch even after the delay threshold.
Possibly https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2462 will help
(In reply to Bharadwaj Raju from comment #5) >. I think it would be a better solution to fix > the issue where *sometimes* holding your cursor over an item doesn't switch > even after the delay threshold. Agreed. I'm all for that too. I even think that's my main complaint here as well.
*** This bug has been marked as a duplicate of bug 462271 ***