Bug 384695

Yes this is really bugging me too because I use Alt+scroll to control the opacity of windows (it's configurable through the settings). Shift + scroll is very standard. It's used in google chrome, vs code, most of ubuntu unity and many others.

I would like to second this. Shift+wheel is what I use in Firefox (with some configuration). I didn't even realize that Alt+wheel is what Okular uses until I saw this bug. I don't understand what Shift+wheel is doing in Okular but it seems not useful - it scrolls diagonally, and rotating the wheel in the opposite direction doesn't return me to where I was. I would expect opposing arrow keys and opposing scroll wheel motions to have opposite effects, that's pretty much a fundamental principle of document navigation. I had just assumed the software was broken.

I'm not sure this is limited to Okular. Horizontal scrolling in many KDE settings dialogues, Dolphin, etc. is achieved with with Alt +.

I can’t find where Okular could handle the Alt key, so I think this is handled in Qt. But it is not documented in QWheelEvent or QScroller, and I can’t find it in Qt::ApplicationAttributes. Upstream bug?

> Right now it is possible using ALT
> I didn't even realize that Alt+wheel is what Okular uses until I saw this bug.
The same here. But it's good to know that for now it is at least doable with kayboard + wheel instead of dragging scroller.

I observed that Okular on Windows has configurable keyboard shortcuts to scroll up/down, why not for left/right? I always need to zoom a page to be able to read comfortably with my eyesight, so I often need to scroll to read the other columns, or see the figure, or read the other page when I'm on double page mode, etc.

Would also prefer more consistent handling of horizontal scrolling between apps and toolkits, both for Okular specific and other KDE/Qt apps in general.

Current behavior of `Shift+Wheel` (scroll an entire screen's worth of content, where regular wheel may not, depending on global settings?  For me regular wheel scrolls a few lines) is also useful IMO but could maybe use a different shortcut?

This behavior comes from Qt. Specifically, QXcbConnection transposes the native wheel event's scroll deltas when populating the QWheelEvent's angleDelta if the Alt modifier key is held. (Search https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/xcb/qxcbconnection_xi2.cpp for "angleDelta.transposed()".) Then, much further down the line, QScrollView reads the angleDelta from the QWheelEvent and fires appropriate signals to the relevant scroll bar(s). So, any new configuration option would need to affect which modifier key QXcbConnection tests for while translating the native wheel events. In short, this is not the responsibility of KDE or of QScrollView but rather of QXcbConnection, which lives in QtBase.

See this Qt bug: https://bugreports.qt.io/browse/QTBUG-75949

(In reply to sevens from comment #7)
> Current behavior of `Shift+Wheel` (scroll an entire screen's worth of
> content[…]) is also useful IMO but could maybe use a different shortcut?

Personally, I would like to see the effects of Shift and Alt (on scrolling behavior of Qt/KDE applications) reversed from what they are now. Shift should scroll the alternative axis, and Alt should activate speed scrolling. That would then agree with every other GUI toolkit.

On Wayland the Alt modifier has no effect. On X11 it allows to scroll horizontally.
On both session types you can scroll horizontally with horizontal wheel.

Operating System: Arch Linux
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.107.0
Qt Version: 5.15.10
Okular: 23.04.3

Andrew: I have filed a bug on qt about the not-very-related Wayland issue, as it appears that the problem is that qt simply did not implement horizontal scrolling on Wayland at all. You can confirm with launching Okular with `XDG_SESSION_TYPE=x11 okular`

https://bugreports.qt.io/browse/QTBUG-118618

I somehow have "shift" in muscle memory too, even as 15+years KDE Plasma daily user (no idea how it happened, I'm confused by it too).

So I would really love it becoming global Plasma option I can flip from alt to shift, so I guess it needs https://bugreports.qt.io/browse/QTBUG-75949 first (resolved by adding it as new option I guess - I don't think it's good to change default without doing some serious survey between user, but I would be completely satisfied by option).

I wouldn't be super fussed about which key I hold down, so long as there is one. That is, one, not, one and also sometimes a different one.

There's a horizontal scroll for Qt and there's a horizontal scroll for every other toolkit, but there's not *a* horizontal scroll for the user.

That's the real problem here. lack of consistency - not consistency with other toolkits, but consistency in usage.

*** Bug 452235 has been marked as a duplicate of this bug. ***

*** Bug 480823 has been marked as a duplicate of this bug. ***

In XFCE is ALT+mouse wheel used for desktop zoom. Also holding ALT allows to drag window from any window area. But would like to use Okular also in XFCE desktop. When use Super-key instead of ALT, then it is used for opening main menu in most desktop environments, not only in XFCE. Then desktop zoom works, but drag windows does not work as it conflicts then. Any other key also does not work instead of ALT. As rest of programs use SHIFT+wheel for horisontal scrolling, Okular uses ALT+wheel -this makes very complex to use shortcut keys with other apps in XFCE and not only - same applies to other desktop environments as well.
Therefore it would be really helpful, if horizontal scrolling shortcut key is configurable. Looks like currently there is no mouse wheel related shortcuts configurable. Used Okular version 25.12.0 currently.

Current workarounds in XFCE are either:
1) temporarily turn ALT off from window dragging, desktop zoom (xfwm4-tweaks-settings), when working with Okular, later turn back on
OR
2) change main menu shortcut key as Super+ESC - although then there is possible to use Super as zoom, window drag, it is unlogical as rest of desktop environments are using plain Super-key to open main menu.

... and just try to remember, that in Okular window we have to use ALT+wheel, other windows SHIFT+wheel for horizontal scrolling.
Same applies to other desktop environments as rest of apps are using SHIFT+wheel for horizontal scrolling. This confuses shortcut keys and changes regular workflow used in other app windows.

Upstream bugreport: https://qt-project.atlassian.net/browse/QTBUG-75949

I thought I should mention that shift+scroll does have a purpose on KDE and that's scrolling faster/further... So I guess that any solution which might allow us to use shift+scroll for horizontal scrolling, should also enable us to use alt+scroll to scroll faster/further.

There's a suggestion in the linked bug to possibly "making Shift+scroll work in addition to Alt+scroll" which might be a problem.

(In reply to pallaswept from comment #19)
> I thought I should mention that shift+scroll does have a purpose on KDE and
> that's scrolling faster/further... So I guess that any solution which might
> allow us to use shift+scroll for horizontal scrolling, should also enable us
> to use alt+scroll to scroll faster/further.
> 
> There's a suggestion in the linked bug to possibly "making Shift+scroll work
> in addition to Alt+scroll" which might be a problem.

Well, per my understanding Okular does it by assigning the shortcut explicitly. So, if Qt changes the defaults, the apps that were using "Shift+scroll" for something else (like Okular) should remain unaffected.

What I mean to say is that the suggestion in that bug

"making Shift+scroll work in addition to Alt+scroll"

Will break things. It must be one, OR the other - because there are two functions to consider, we need two bindings available, and this function can't take two for itself.

I am confused, can you please elaborate what will it break?

(In reply to Konstantin Kharlamov from comment #22)
> I am confused, can you please elaborate what will it break?

Now: 
Shift+scroll = fast scroll
Alt+scroll = side-scroll
Shift+Alt+scroll = fast side-scroll

If shift and additionally alt will trigger side-scroll, then there is no bind available for fast-scroll.

(In reply to pallaswept from comment #23)
> (In reply to Konstantin Kharlamov from comment #22)
> > I am confused, can you please elaborate what will it break?
> 
> Now: 
> Shift+scroll = fast scroll
> Alt+scroll = side-scroll
> Shift+Alt+scroll = fast side-scroll
> 
> If shift and additionally alt will trigger side-scroll, then there is no
> bind available for fast-scroll.

Okay, now I'm even more confused. I replied previously that if an app processes a hotkey explicitly (such as with Shift+scroll in Okular), that should override any other default binding. You now say the problem holds nonetheless. Why?

There are two functions, and two bindings. If one function takes two bindings, then there is one function left with zero bindings available.

(In reply to pallaswept from comment #25)
> There are two functions, and two bindings. If one function takes two
> bindings, then there is one function left with zero bindings available.

If Qt would default both "Alt+scroll" and "Shift+scroll" to horizontal scrolling, and then Okular overrdes the latter with "fast scrolling", you just get the old behavior where "Alt+scroll" is horizontal scroll and "Shift+scroll" is "fast scroll".

Why all the laser focus on Okular? Fast scrolling with Shift+Wheel is default Qt behavior in all Qt applications, not just Okular. I too would love to see Qt be configurable with respect to which modifier key speeds up scrolling and which switches scrolling to the opposite axis, but I would *not* want to see Qt's default behavior be that it accepts either of two modifier keys for alternate-axis scrolling but loses the ability to scroll quickly.

Ideally I would want to see each of the two scrolling modifiers be configurable with respect to which modifier key activates it (and not limit the choices to just Shift and Alt), but if we can't have configurability, at least give us behavior consistent with other toolkits.

Oh, so that's what was missing from the discussion: that "Shift + scroll" already has some default binding in Qt (not in Okular specifically). I didn't even know about that, but now that I'm testing in Spectacle, I notice indeed that holding down shift makes scroll go faster.

Well, that complicates things.

Though, I find it strange that Qt devs never commented about it on the report, which has been created back in 2021 🤔 Is it really the Qt default binding, or perhaps is it KDE frameworks…?