linux: Use kirigami mouse handling if available

[ReillyBrogan]

Qt6 changed the mouse scroll wheel handling for QtQuick to a type that mimics how touch pads/screens work, which most people find feels very poor. KDE fixes this by creating a custom type which re-implements the QtWidgets handling (see https://invent.kde.org/frameworks/kirigami/-/merge_requests/415).

On Matrix Nico has expressed a desire not to have to deal with compiling Kirigami for Windows and Mac, which is understandable. Linux users on the other hand almost always have kirigami available in their package repos which sidesteps that particular issue. We can search for Kirigami at build time and if present define a QML context property to allow it to be used, which should fix this issue for Linux users at least.

Helps with #1819 (which won't be completely resolved until this is working for Windows and Mac as well).

[deepbluev7]

I'm still torn on this:

On the one hand, we had a similar solution before: https://github.com/Nheko-Reborn/nheko/blob/v0.11.3/resources/qml/ScrollHelper.qml
We removed it since Qt fixed most of the scrolling bugs in Qt6. Otoh the scroll speed issue is quite annoying and might take quite a while to be fixed properly upstream (I don't even know if there is an issue for it upstream).

There is also the issue that this enables it only at compile time, which means packagers need to now have kirigami available to build Nheko with the proper scroll speed. For that we maybe could just vendor that piece of code (with the intention of hopefully removing it soon!). That would also resolve this on macOS and Windows, although I think macOS actually seems mostly fine (because it uses different scroll phases on macOS).

So maybe there is a better solution for it if we either can check for kirigami dynamically at runtime (maybe by trying to load the module?) or vendoring just the WheelHandler code? Hopefully someone setting their QT_STYLE to kirigami wouldn't break anything in any case...

[ReillyBrogan]

Otoh the scroll speed issue is quite annoying

Yes, it seems that it's one of the most common issues mentioned in the matrix channel by far, and I think most people would prefer it be solved rather than wait for a nebulous upstream Qt fix. Also, on Solus we've been using a variant of this kirigami patch for a while now and neither I nor any other user has noticed any issues with it.

There is also the issue that this enables it only at compile time

Yes, the development files for kirigami will need to be present at build time, then the QML modules at runtime. At least nheko will crash quickly if the QML module is not present at runtime with an appropriate error to let the packager know that they need to add kirigami as a rundep.

if we either can check for kirigami dynamically at runtime

This might be possible but TBH I don't know how to go about it. My Qt/QML skills aren't much more advanced than you see here.

vendoring just the WheelHandler code

This looks possible, the code is fairly self-contained and it should be possible to extract it. Not really something I can tackle myself though.

We could always merge this as the "easy" fix and then refine it later.

[vaxerski]

I've rebased this on master and tested, and it does indeed improve the situation greatly. however the scrolling is still considerably slower than other apps (e.g. dolphin, firefox, chromium) Actually, disregard. Seems on par, just that some views speed up the scrolling.

I still do believe it's miles better than the current situation, scrolling is unusable on master.