Bug 503998

Summary: 3 Improvements to Autoscrolling
Product: [Plasma] kwin Reporter: Nikoichu <nikolay_anzarov>
Component: inputAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: wishlist CC: cwo.kde, duha.bugs
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Unspecified   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

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.