[Feature Request] Implement kinetic scrolling

[Hi-Angel]

Is your feature request related to a problem?

"Kinetic scroll" (used mostly with touchpads) is when you make a text to scroll, and scrolling does not immediately stop, but instead just slows down, and then stops. Telegram has this behavior on mobile platforms (tested on Android).

Describe the solution you'd like

Enable kinetic scrolling. Qt5 provides this with QScroller class, but Telegram has to enable it explicitly.

[ghost]

If I'm right, this is actually present in tdesktop v 1.8.15. It works on the following OS just fine: Windows 10, Linux Mint (Cinnamon)

I've also asked a question related to this issue: #6930

[Hi-Angel]

If I'm right, this is actually present in tdesktop v 1.8.15. It works on the following OS just fine: Windows 10, Linux Mint (Cinnamon)

Hmm, this is odd. I have 1.8.15 right now, and there's no kinetic scrolling. Archlinux here.

[Hi-Angel]

@damnfella I have 1.9.3 right now, and sure there's no kinetic scroll. By any chance, aren't you running a synaptics driver? If you do, then it has implemented kinetic scroll internally by mistake. In this case it's kinda irrelevant to Telegram.

[ghost]

@Hi-Angel I understand now, sorry. I do have a synaptics driver for my touchpad.

I'm not sure what I should do about the weird scrolling in 1.9.3 now.

[Pointedstick]

As @Hi-Angel says, if you're on Linux and using the old unmaintained Synaptics driver, you may have fake kinetic scrolling provided by the driver. If you're using the new and actively developed Libinput driver, then it's up to the toolkit/app to implement this behavior. In this case it would mean Telegram turning it for scrollviews using the appropriate QScroller API, as mentioned earlier.

[john-preston]

@Pointedstick If I understand correctly, QScroller allows the area to be scrolled by mouse by pressing and dragging, which is not what is expected of the messages history area.

[Hi-Angel]

@Pointedstick If I understand correctly, QScroller allows the area to be scrolled by mouse by pressing and dragging, which is not what is expected of the messages history area.

The QScroller::TouchGesture Nate mentioned in this comment is related to touch events according to docs. I.e. not to a mouse scroll.

[john-preston]

@Hi-Angel I've read this:

https://www.qtcentre.org/threads/55778-Scrolling-using-QScroller-class

And they say that "QScroller doesnot work on QScrollArea when QScroller::TouchGesture is used for touch devices." So I'm not sure if it will help.

Kinetic scrolling by touch events was implemented manually in tdesktop, but I guess that touchpads are not sending touch events to QScrollArea, they send mouse wheel events instead.

[Hi-Angel]

@Hi-Angel I've read this:

https://www.qtcentre.org/threads/55778-Scrolling-using-QScroller-class

And they say that "QScroller doesnot work on QScrollArea when QScroller::TouchGesture is used for touch devices." So I'm not sure if it will help.

Kinetic scrolling by touch events was implemented manually in tdesktop, but I guess that touchpads are not sending touch events to QScrollArea, they send mouse wheel events instead.

Well, the same post also says it works on other widgets:

2. QScroller works using QScroller::LeftMouseButtonGesture and QScroller::TouchGesture on QListViews/treeviews on touch devices and desktop

So might depend on a widget. Also note that these are just someone's observations from 2013 year. I.e. they may have done something wrong or it may have been fixed.

[john-preston]

@Hi-Angel Perhaps it could be tested. But right now all the scrolling is done in the QScrollArea-s, so any changes should work fine with QScrollArea (or they'll become a huge task).

[Pointedstick]

@Pointedstick If I understand correctly, QScroller allows the area to be scrolled by mouse by pressing and dragging, which is not what is expected of the messages history area.

The QScroller::TouchGesture Nate mentioned in this comment is related to touch events according to docs. I.e. not to a mouse scroll.

Am I reading it wrong? I see:

The gesture recognizer will only trigger on touch events. Specifically it will react on single touch points when using a touch screen and dual touch points when using a touchpad.

So yeah, you'd get kinetic scrolling when using a laptop touchpad. Probably it should be be implemented for mousewheels; that's always controversial and a lot of mouse users hate it. But it's pretty much always a nice thing when using a touchpad.

[Hi-Angel]

@Pointedstick If I understand correctly, QScroller allows the area to be scrolled by mouse by pressing and dragging, which is not what is expected of the messages history area.

The QScroller::TouchGesture Nate mentioned in this comment is related to touch events according to docs. I.e. not to a mouse scroll.

Am I reading it wrong? I see:

The gesture recognizer will only trigger on touch events. Specifically it will react on single touch points when using a touch screen and dual touch points when using a touchpad.

So yeah, you'd get kinetic scrolling when using a laptop touchpad. Probably it should be be implemented for mousewheels; that's always controversial and a lot of mouse users hate it. But it's pretty much always a nice thing when using a touchpad.

I don't think there's any disagreement on that part. The discussion currently is about QScroller not working with QScrollArea per some forum comments. And @john-preston also made a very interesting point here. If I correctly understand him, he says they already have a custom implementation of kinetic scrolling on QScrollArea, but apparently it doesn't seem to work on Linux.

I see there might be a relation between these two points. I think best way to move forward is if someone shows a working minimal example of kinetic scrolling with QScrollArea. I may give it a try on the weekend.

[Hi-Angel]

Okay, so, I crafted up a minimal example of using QScroller with QScrollArea, and I confirm this does not provide kinetic scrolling. When I swipe the area with touchpad, it scrolls until the swipe happens and then just stops. So it is an interesting question why this does not work.

The example:

#include <QApplication>
#include <QLabel>
#include <QScrollArea>
#include <QScroller>

void gen_label_text(QLabel& label) {
    const char sentence[] = "'th sentence here\n";
    QString text;
    for (int line = 0; line < 1e3; ++line) {
        text += QString::number(line) + sentence;
    }
    label.setText(text);
}

int main(int argc, char **argv) {
    QApplication app (argc, argv);
    QLabel label;
    gen_label_text(label);
    QScrollArea qsa;
    qsa.setWidget(&label);

    QScroller *scroller = QScroller::scroller(&label);
    QScroller::grabGesture(qsa.viewport(), QScroller::TouchGesture);

    qsa.show();
    return app.exec();
}

To compile it use:

g++ test.cpp -o a -O0 -g3 -fPIC $(pkg-config --cflags --libs Qt5Gui Qt5Widgets)

[Hi-Angel]

@Pointedstick do you happen to know: the commit that you referred to, which implements kinetic scroll in Dolphin — does it only work for touch-scroll? Or for wheel-scroll as well?

The reason I'm asking is because I debugged the minimal example from prev. comment and I figured that I see no touch-scroll events in QScrollArea. Instead I see events called "Wheel". That makes me wonder if it's a problem unique to QScrollArea or not.

Debug code

```c++ #include #include #include #include #include #include void gen_label_text(QLabel& label) { const char sentence[] = "'th sentence here\n"; QString text; for (int line = 0; line < 1e3; ++line) { text += QString::number(line) + sentence; } label.setText(text); } /// Gives human-readable event type information. // Credits to https://stackoverflow.com/a/22535470/2388257 QDebug operator<<(QDebug str, const QEvent * ev) { static int eventEnumIndex = QEvent::staticMetaObject .indexOfEnumerator("Type"); str << "QEvent"; if (ev) { QString name = QEvent::staticMetaObject .enumerator(eventEnumIndex).valueToKey(ev->type()); if (!name.isEmpty()) str << name; else str << ev->type(); } else { str << (void*)ev; } return str.maybeSpace(); } struct MyClass : public QScrollArea { bool event(QEvent* ev) override { qDebug() << "handling an event " << ev; return QScrollArea::event(ev); } }; int main(int argc, char **argv) { QApplication app (argc, argv); QLabel label; gen_label_text(label); MyClass qsa; qsa.setWidget(&label); QScroller *scroller = QScroller::scroller(&label); QScroller::grabGesture(qsa.viewport(), QScroller::TouchGesture); qsa.show(); return app.exec(); } ```

[Hi-Angel]

Okay, so, I searched all over Qt docs on that matter, and I can say this is either a problem in Qt documentation or in the Qt widget. Whatever it is, this bug would belong to Qt bugtracker, so I reported it there

[Pointedstick]

Thanks, I totally believe that there's a Qt bug here. Nice job reporting it.

[stale[bot]]

Hey there!

This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[Hi-Angel]

Well, although the obvious path to solution got stuck on Qt bug, but I'm not sure it invalidates the report, since there probably could be some creative workaround. It was mentioned, that the problem is specific to the widget and Nate showed here examples where it works for other widgets, so… I'd say, let's leave it open in case someone figures a workaround.

[stale[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[Hi-Angel]

Still relevant

[gmankab]

Still relevant

[juanpc2018]

TDesktop 3.6.1x64 for Windows has Kinetic Scroll, a bit tight for my taste. it should slip a bit more. decay curve is too fast for my taste... also has a problem, Not smooth, has jitter.

[juanpc2018]

24271

https://odysee.com/@Dissent:c/tdesktop30fps:1

happens on both sides of Telegram, Left Subscribed / Following Channels Right Channel Content.

Telegram has very low Ram usage... problem is Not related to loading content only, because Left Window also has a problem., and only needs to load cache.

Windows81x64 3.6.1x64

i recorded the video with an external HDMI PCIe recorder, and other PC. my PCIe hdmi capture card is old, does Not allow 60fps, only 30fps at FullHD.

Control Panel Settings: Mouse Wheel 2 lines. Microsoft All-In-One Keyboard Trackpad Nvidia GT 730 GPU

browser.yandex is the most smooth scroll, but still has problems in some websites like this: https://www.swpc.noaa.gov/communities/space-weather-enthusiasts

but Not this: https://www.microsoft.com/ru-ru/accessories/products/keyboards/all-in-one-media-keyboard?activetab=overview:primaryr2

https://www.microsoft.com/en-ww/accessories/products/keyboards/all-in-one-media-keyboard?activetab=overview%3aprimaryr2

[juanpc2018]

i have bad news...

Kubuntu 20.10 Groovy Gorilla, Mac Mini 2014 Iris Graphics 5100 GPU SSD SATA-3 6Gbps, Disk Tools Benchmark 556MB/s avg read. 278MB/s write.

Scroll jitter is insane... like 3 frames per second. everything is chopped, skipps frames like crazy.

i know the GPU is inferior to Nvidia GT 730, Yandex browser also feels strange, but Not this, its insane...

Telegram Latest Edge version 3.6.2x64

https://en.wikipedia.org/wiki/Mac_Mini#Third_generation_(Unibody) https://en.wikipedia.org/wiki/Intel_Graphics_Technology#Haswell

i can recor a video if you want to cry.

[juanpc2018]

https://odysee.com/tdesktop30fps_1:dc5cbc0e0864de7da6fb11fd8f29a4a057928c9e with MS All-In-One Trackpad .

i think i found the root of the problem... problem is related to the type of USB Mouse or Trackpad...

i changed to a Microsoft Wireless Mouse 5000 does Not slip & slide like the Microsoft AIO Trackpad with 2 fingers, BUT... moving the Wheel fast, looks smooth, same Wheel settings 2 lines per click, but the mouse wheel has no steps, gives a smooth feeling. mouse that have steps in the wheel, make noise, and feel weird a vibration hit in the finger bones.

when moving slow, the stepness / staircase feeling can be detected visually, but smaller.

in OSX the wheel has severe problems, after Sierra when used with a Non-Apple Trackpad or Mouse, there are many 3rd party apps to tweak the settings of OSX to solve the problem. some browsers in OSX override Mouse settings, and create their own custom settings to avoid the problem.

http://xahlee.info/kbd/mouse_dpi.html http://xahlee.info/kbd/mouse_polling_rate.html

https://www.gearrate.com/en/guide/mouse-dpi/ https://www.techadvisor.com/how-to/pc-peripheral/how-check-mouse-dpi-3679433/ https://www.mouse-sensitivity.com/dpianalyzer/

[juanpc2018]

found a better way to explain the problem.:

mouse wheel 1 vs 10 scroll lines. https://odysee.com/@Dissent:c/Wheel-Lines-1-vs-10:5

lines are not pixels, 1 line still feels a bit coarse when moving slow, at 1 line steps at 1080p but visually acceptable, almost fools human eye. vs. 10 jumps "coarse", Not smooth transition.

with 1 setting i need to move very fast the mouse wheel to scroll the screen at an acceptable speed. does Not increase speed dynamically. does Not have smooth transition between 1 line and the next. video pause when moving scroll.

Same happens with MIDI volume cc7, MIDI its 7-Bits 0 to 127 steps "128", coarse enough to be noticeable when making a fade-in or fade-out, DSP mixers like Yamaha DSP Factory pci or Digital consoles 01v 03d 02r, implemented decades ago an algorithm to make smooth volume transitions between midi steps. for example, Audio 16-Bits = 65536 steps, MIDI 7-Bits 128 steps = 512 steps jumped. Audio 20-Bits = 1048576 steps. MIDI 7-Bits 128 steps = 8192 steps jumped. Audio 24-Bits = 16777216 steps. MIDI 7-Bits 128 steps = 131072 steps jumped.

Smooth Volume algorithm, gradually change values between MIDI steps, Not jumping 512 steps.

same: FullHD has 1920x1080x30fps 1080 / 24fps = 45 1080 / 30 fps = 36 1080 / 60fps = 18 1080 / 120fps = 9

In Sony TVs is called MotionFlow, in Samsung TVs is called AutoMotion Plus in LG TruMotion.

https://ru.wikipedia.org/wiki/Motionflow https://ru-m-wikipedia-org.translate.goog/wiki/Motionflow?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp https://en.wikipedia.org/wiki/Motion_interpolation https://en.tab-tv.com/?page_id=7203

[juanpc2018]

tested pearOS Monterrey in acer Aspire 5 Touchpad, scroll looks smooth.

each hardware scroll algorithm behaves differently. Mouse Wheel scroll Jumps, acer Touchpad is smooth. microsoft aio touchpad has weird jitter, jumps like a mouse wheel when slow, and slides like a touchpad when fast, but slides like a water slide in a aquapark. etc...

in linux there is imwheel software to improve mouse wheel scroll. when touch pad is a fake mouse wheel.

Some softwares like Yandex & Firefox try to solve the HW differences problem, creating its own scroll algorithm. but other softwares do Not, like Telegram Desktop. are HW transparent, if HW has scroll problems Telegram Desktop scroll shows.

[ilya-fedin]

This issue is now a part of #25126

[Hi-Angel]

Can somebody confirm if kinetic scroll works in Desktop (non-mobile) Telegram at least on some OS?

I'm kinda confused now, because @ilya-fedin asked me a question on the Qt bugrepot (which I totally forgot about, sorry for replying late) about whether it's really QScrollArea-specific. While I was writing a reply I noticed there are contradicting reports about the state of the feature on various OSes.

E.g. @Pointedstick says here it works on Windows, but then this issue marked as a dup to this one claims: no, it doesn't.

So, I think we need to clarify: does Desktop Telegram have kinetic scrolling right now at least on some OSes? Or is the feature is completely unimplemented?

The reason I'm asking is because I initially thought the QScrollArea bug may or may not be present on the system, and so the correct fix is inside Qt. But this comment implies it may have never worked anywhere at all, in which case the correct way to proceed might be not to wait for the report to resolve (which now turns into more of a documentation problem), but instead to search for some widget hooks inside Qt that would allow to implement it some other way.

[ilya-fedin]

I believe it relies on OS drivers. I.e. if OS drivers provide kinetic scrolling, it works, if not, it doesn't work. E.g. @john-preston claims it works for him on his macbook on both host macOS and Windows VM in Parallels.

Yes, I believe Qt just doesn't provide kinetic scrolling for widget applications at all on non-touchscreen devices and they should implement that on their own, but as @john-preston has already pointed in https://github.com/telegramdesktop/tdesktop/issues/6746#issuecomment-633933604 this becomes a huge task (and given the priorities, I tend to think this won't be ever implemented, sorry).

[Hi-Angel]

I believe it relies on OS drivers. I.e. if OS drivers provide kinetic scrolling, it works, if not, it doesn't work. E.g. @john-preston claims it work for him on his macbook on both host macOS and Windows VM in Parallels.

This is pretty interesting, because implementing scroll in a driver is a buggy way, so it's odd if Mac OS does that. The deprecated Linux "synaptics" (replaced by libinput) driver provided that as well, but this breaks apart when:

1. You press a modifier key like Ctrl before inertia stopped, which leads to the application incorrectly interpreting that as a Ctrl+Wheel UP/DOWN (because only driver knows those scroll events are fake)
2. An application implements a kinetic scroll, which results in conflict with a driver

I don't remember seeing any complaints on the matter from Mac OS users, so I'm not sure it's really in the driver.

[ilya-fedin]

Well, @john-preston claims it works for him on Windows without any changes in code while some people on GitHub claim it doesn't work for them on Windows, so I don't see any other place rather than drivers that could affect the behavior in such a way.

On macOS, though, it may be somewhere in OS itself rather than drivers. Either way, macOS has a limited hardware testing surface, this means software developers see kinetic scrolling is already provided by the OS and don't invent their own implementations, adjusting to any caveats (like pressing modifiers) system behavior provides, so you won't see such bugs.

[ilya-fedin]

I believe the issue should be named "Implement kinetic scrolling" or just "Kinetic scrolling" rather than "Enable kinetic scrolling", as it doesn't seem it's as easy as just enabling something.

[ilya-fedin]

A way more realistic path for Linux users may be to request the feature on OS level, e.g. some request in Wayland protocol to opt-in transparent kinetic scrolling support, so Qt and other toolkits/applications not willing to spend time on reinventing the kinetic scrolling can just opt-in to it and the compositor starts producing scrolling events in kinetic style, rather than implementing it from scratch in each & every client.

[Pointedstick]

An opt-in protocol for apps/toolkits that don't want to do this themselves could conceivably work, but compositors would have to implement support for it. Given that the only major toolkit prominently lacking support for this is Qt (for QtWidgets in general and for KDE's QtQuick apps styled with our qqc2-desktop-style package specifically), I imagine the only compositor interested in adding support for it would be KDE's KWin, given that it's most commonly used in a Qt-heavy environment. Other compositors probably won't care to, since the toolkits they typically use already offer toolkit-based inertial/kinetic touchpad scrolling. Which means the work in KWin would in all likelihood be done by KDE people. And if we're going to do work on that, it would probably make more sense to just fix our qqc2-desktop-style to add inertial/kinetic touchpad scrolling so that QtQuick-based apps all get it for free.

If that happens, the only major development target still lacking inertial/kinetic touchpad scrolling at the toolkit level would be QtWidgets. Which is unfortunate. But, it's already possible to get inertial/kinetic scrolling yourself in your QtWidgets-based app, by adding QScrollers object to your scrollviews and applying the relevant properties to them as mentioned earlier. So I think for sure the path of least resistance for Telegram is to just do that.

[ilya-fedin]

by adding QScrollers object to your scrollviews and applying the relevant properties to them as mentioned earlier.

As also mentioned earlier, QScroller doesn't work. It handles touch events while QPAs generate mouse wheel events for touchpads. In other words, QScroller provides kinetic scrolling only for touchscreens and there's a bug in the documentation.

[ilya-fedin]

Particularly, in Wayland case, touchpads are presented with wl_pointer objects and Qt differentiates mouses from touchpads by checking for pointer-gestures protocol support: https://github.com/qt/qtwayland/blob/f47a3df73633a21d7e0e4fa90f9d2a32b79b9a38/src/client/qwaylandinputdevice.cpp#L431-L447 Practically, this means every mouse is a touchpad from Qt PoV: https://bugreports.qt.io/browse/QTBUG-112432

The pointer-gestures protocol has no flick gesture, so Qt can't get touch points even in theory from the system. All it gets from the compositor is mouse wheel events. But even if there were such a gesture in the protocol, this would mean changes in QScroller are required as Qt provides such events as native gestures, not as touch events.

I don't know whether Qt can or can't get raw touch events for touchpads on X11 in theory, I haven't explored that part, but it practically doesn't do so for Windows nor X11. There's some touch handling for touchpads in macOS QPA, but not sure whether it's usable for QScroller. There's no need in QScroller on macOS after all as macOS provides native kinetic scrolling.

QScroller starts to work with -plugin evdevtouch:force_window, even with the example from https://github.com/telegramdesktop/tdesktop/issues/6746#issuecomment-635005342, but touchpad acts like a touchscreen and the window consumes even the events outside of the window, so it's not something really usable.

[Hi-Angel]

@Pointedstick as a side note, if there will be decision that such Wayland protocol is necessary, the algorithm itself is better to implement inside libinput.

[Pointedstick]

Unless something significant has changed, I don't anticipate that working since the Libinput maintainer Peter Hutterer is very much against doing inertial/kinetic scrolling in the input driver.

It sounds like we're stuck unless someone either submits some fixes to Qt, or ports Telegram to QtQuick (or a non-Qt toolkit).

[Hi-Angel]

Unless something significant has changed, I don't anticipate that working since the Libinput maintainer Peter Hutterer is very much against doing inertial/kinetic scrolling in the input driver.

I think this is different. The reason Peter is against is because inertia in the driver being always enabled leads to bugs like ones I mentioned earlier. However if we're talking about a Wayland protocol that would allow Compositor to apply inertia on a per-client basis, this would imply much finer-grained control over inertia, which I think would allow to avoid bugs of that sort. In particular, the point about pressing a modifier key while inertia events are being sent may be solved because in this case a compositor would ideally know which events are fake, so it may simply stop sending them once a key is pressed.

[ilya-fedin]

There was some related research for the stories UI implementation. Conclusions:

1. macOS indeed provides system APIs for kinetic scrolling. Qt abstracts it using QWheelEvent::phase()/Qt::ScrollPhase, particularly the Qt::ScrollMomentum that points to the fact the user no longer scrolls but it's the kinetic effect.
2. Indeed, some Windows touchpad makers do implement the kinetic scrolling with WHEEL_DELTA in driver. Both Firefox and Chromium use the Direct Manipulation API for their scrolling. Qt in its best traditions doesn't support it. The Desktop App Toolkit tdesktop is based on now has support for Direct Manipulation API via its RpWindow class which the main window is based on so Windows users should now have way smoother scrolling in any part of the main window and other windows based on the RpWindow class. According to @john-preston's tests it feels waaaaaay better for a touchpad user. The API has DIRECTMANIPULATION_INERTIA event which gets translated to Qt::ScrollMomentum now and that smells like OS level kinetic scrolling support so maybe every Windows touchpad user will have kinetic scrolling now...
3. No really good news for Linux... The Qt's xcb backend doesn't support scroll phases at all, the wayland backend does support Qt::ScrollBegin, Qt::ScrollUpdate and Qt::ScrollEnd but not Qt::ScrollMomentum what is totally expected as @Pointedstick has stated there's no kinetic scrolling support on Wayland level and no plan to bring it. This renders Linux the API outsider, again. This also means any work to better support such system APIs (as both mainstream systems have them) would be irrelevant for Linux.

The Qt's wayland backend is also full of funny code such as:

[ilya-fedin]

And macOS indeed the only platform having touch events produced by touchpad so the QScroller is relevant only for macOS touchpads apparently.

[alba4k]

so no hope to get this in a reasonably close future, not even on wayland?

[ilya-fedin]

Unless someone of you folks want to work on that, no. I don't imagine hired developers to work on that, Linux support is mostly done by the community. Windows and macOS support seem to be the only company's priority and kinetic scrolling is provided by the OS/drivers there.

Another way is to get support for this in either Qt or display servers (Xorg, mutter, kwin, etc). But for that you should bug Qt/display servers respectively.

[ilya-fedin]

If anyone wants to fix Qt (QScroller), one possible way is to make the windows/xcb/wayland QPAs send touch events for touchpads just like the cocoa QPA does. That would likely make existing QScroller code work.

Another possible way is to fix QScroller itself so it works with mouse wheel events (that's what touchpads generate on Windows, X11 and Wayland) like I mentioned earlier.

[lilydjwg]

so it works with mouse wheel events

It shouldn't work this way on Wayland. Kinetic scrolling should happen with touchpads but not (ordinary) mouse wheels. And from the Wayland side, touchpads generate smooth, continuous scroll events, mouse wheels generate discrete ones. They are different and GUI applications should be aware of the difference (for e.g. kinetic scrolling and precise scrolling).

[ilya-fedin]

continuous scroll events

this is represented by pixelDelta and phase on QWheelEvent I guess