Bug 503998 - 3 Improvements to Autoscrolling
Summary: 3 Improvements to Autoscrolling
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: input (other bugs)
Version First Reported In: unspecified
Platform: unspecified Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-05-10 10:03 UTC by Nikoichu
Modified: 2025-05-10 13:38 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikoichu 2025-05-10 10:03:22 UTC
Full thead detailing reasons and implementations in-depth:
https://discuss.kde.org/t/improvements-to-autoscrolling-middle-click-and-drag-to-scroll/34011/1

Autoscrolling is amazing, but unusable in its current implementation, because it conflicts with any program that wants to use Middle Click for its own purposes. Here are 3 things that can fix the situation. Ideally, all 3 should be implemented for maximum effect.

    -Configure the setting on a per-window basis.
There are already so many things you can configure on a per-window or per-application basis in KDE, I was surprised this option wasn’t one of them.

    -Make an easy way to switch it on and off via a global hotkey or Scroll Lock.
Having to enter the settings every time you want to switch it on/off is a pain. I propose to use the status of Scroll Lock (with an option to disable the default behaviour of Scroll Lock, which I doubt anyone uses anymore) to turn Autoscrolling on and off, or alternatively be able to bind a global hotkey to toggle it.

    -Make it possible to rebind the hotkey that triggers Autoscrolling.
It doesn’t have to be middle click - give the users the option to rebind it to anything they want. For example, a lot of (gaming) mice have additional buttons that could serve the purpose perfectly.
Comment 1 cwo 2025-05-10 11:44:57 UTC
Some of these seem reasonable and implementable (though there is a tradeoff with interface complexity). But bug reports that bundle multiple feature requests together that will have completely separate implementations is a bad idea, it makes any discussion harder to follow and it's much harder to track progress as the report is less actionable.

Please resubmit these three suggestions as individual feature requests.
Comment 2 Nikoichu 2025-05-10 13:38:04 UTC
(In reply to cwo from comment #1)
> Some of these seem reasonable and implementable (though there is a tradeoff
> with interface complexity). But bug reports that bundle multiple feature
> requests together that will have completely separate implementations is a
> bad idea, it makes any discussion harder to follow and it's much harder to
> track progress as the report is less actionable.
> 
> Please resubmit these three suggestions as individual feature requests.

Thank you for the input. I separated it into these 3 suggestions:
https://bugs.kde.org/show_bug.cgi?id=504010
https://bugs.kde.org/show_bug.cgi?id=504011
https://bugs.kde.org/show_bug.cgi?id=504013

I also changed the component to "libinput", I don't know if it's more correct than just "input". Sorry if I mis-categorized it.