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