Created attachment 131309 [details] The startmenu list before (left) and after (right) hovering over the list with the mouse. SUMMARY Do not automatically scroll the startmenu lists on mouse hover over the lowest (or highest) item in the list. STEPS TO REPRODUCE 1. Open the startmenu by clicking on the icon in the left bottom corner of the screen 2. Move the mouse sideways to hover over a list that is so long that it does not fit within the height of the startmenu and thus has a scrollbar 3. Move the mouse upwards to select a specific entry in the list OBSERVED RESULT The list scrolls downwards for a bit and every entry changes its position upwards. I have to readjust where i need to move the mouse to select the item i want. Also, i can no longer see the title on the top of the list, or the topmost item, because it was scrolled away. EXPECTED RESULT The list does not scroll unless i use the scrollbar or scrollwheel. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.19.4 KDE Frameworks Version: 5.73.0 Qt Version: 5.15.0 Kernel Version: 5.8.3-arch1-1 OS Type: 64-bit
*** This bug has been marked as a duplicate of bug 387797 ***
Un-duping this because it needs to be fixed separately (if we do decide to apply the workaround for it that we applied for the Clipboard and other System Tray applets.
Needs the same fix as Bug 387797.
Git commit 05a4d828fee1055d6674d0655462acc8b22fba28 by Noah Davis. Committed on 05/12/2024 at 10:49. Pushed by ndavis into branch 'master'. Kickoff: Add a setting to enable selecting categories on hover Related: bug 452636, bug 483205 M +4 -0 applets/kickoff/package/contents/config/main.xml M +6 -7 applets/kickoff/package/contents/ui/AbstractKickoffItemDelegate.qml M +10 -0 applets/kickoff/package/contents/ui/ApplicationsPage.qml M +6 -0 applets/kickoff/package/contents/ui/ConfigGeneral.qml M +2 -2 applets/kickoff/package/contents/ui/KickoffGridView.qml M +2 -2 applets/kickoff/package/contents/ui/KickoffListView.qml M +10 -0 applets/kickoff/package/contents/ui/PlacesPage.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/05a4d828fee1055d6674d0655462acc8b22fba28
With https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2658, this will no longer happen in the category list by default as of Plasma 6.3.0. Lowering severity and changing title accordingly.
Please let me know if I should file this separately, but, I just came by to file a bug because this feature has gone missing in 6.3 > EXPECTED RESULT > The list does not scroll unless i use the scrollbar or scrollwheel. That's cool if your fingers work :D This is now optional for the categories which is great, but completely absent from the menus themselves. Can we please have an option, like with the categories?
I don't understand what you're referring to or asking for, sorry. If it isn't related to the issue reported in this bug report (which is still valie), can you please open a new bug report/feature request for it? Thanks!
Prior to plasma 6.3, if I hovered over the edge of a menu where it could be scrolled, it would scroll. This worked in the categories list and in the grid view. This was very convenient as it negated the need to either a) move the mouse to the scrollbar and click and drag it or b) use the scroll wheel. Simply point where there is more icons, and it will scroll to them. This issue seems to consider this feature to be disruptive, but I always saw it as an accessibility feature and I'd really like it back! It seems to have disappeared along with the other hover-driven navigation becoming optional, as per post 4 here.
What you're describing is unfortunately something we got tons of bug reports about (see Bug 387797). I don't believe we'll be bringing it back due to the level of disruption it seems to cause most people, and the behavior is waaaaay too niche to make configurable. As for why Kickoff isn't affected anymore in Plasma 6.3.0, it's actually just a side effect of us disabling hover-to-switch by default. If you turn that back on, you'll get back the behavior we're talking about as well. …at least until this bug report is fixed. :)
(In reply to Nate Graham from comment #9) > and the behavior is waaaaay too niche to make configurable. I mean, it being a problem only for a minority, is kinda par for the course with a11y stuff. Plus we already got an option for hover-driven navigation, just, it doesn't work for scrolling, only for 'clicking' the categories. Also, the video linked on that bug shows two different issues and conflates them in the one bug that killed both behaviours https://bugsfiles.kde.org/attachment.cgi?id=109319 The thing at 2 seconds, that's obviously a problem. Probably even more so from an a11y perspective. The thing at 6 seconds is different, and useful. I can totally see how it might not be immediately obvious to an able-bodied person why this might have been useful (just as it never occurred to me that people might not like it), and I can definitely see that a lot of effort went into removing this, so reconsidering it might not be attractive, but... It really seems like mistakes were made. Sorry man please don't shoot the messenger.
The things at 2 seconds and 6 seconds are exactly the same thing: hovering over a partially visible item scrolls the view to see all of it. I can see how this looks kind of like an accessibility feature, but it's really not, because it only happens when hovering over a partially-visible item. Once that item comes into view, you can't keep scrolling in that direction anymore. A proper accessibility-focused implementation would allow scrolling up and down at any time, not just when hovering over a partially visible item. The actual behavior is simply a bug.
(In reply to Nate Graham from comment #11) > The things at 2 seconds and 6 seconds are exactly the same thing: hovering over a partially visible item scrolls the view to see all of it. The context makes the difference - 2 seconds, the cursor just entered the view, but at 6 seconds, the cursor is in the view, and 'pushes' the edge out. Anyway that doesn't matter because > A proper accessibility-focused implementation would allow scrolling up and > down at any time, not just when hovering over a partially visible item. > > The actual behavior is simply a bug. I believe you... mine would just keep scrolling, like that 'proper' implementation. It was a bit weird about it, though. I guess I did something "special" with that bug and I've been thinking it was by design all this time XD Oh well good riddance to it then!
Your idea for an accessibility feature is an interesting one though. It's just that it would need to actually be implemented as such!
(In reply to Nate Graham from comment #13) > Your idea for an accessibility feature is an interesting one though. It's just that it would need to actually be implemented as such! It might be cool but your 'here's a list of places we need to fix this' tells me that it's an absolute monster. I was concerned that a deliberate feature was being accidentally removed but if this is an accidental bug being deliberately removed I'll be cheering on the sidelines with everyone else :D Apologies for the distraction. Perhaps my comments here should be marked as spam.