[Feature Request] Implement kinetic scrolling #6746
Comments
|
If I'm right, this is actually present in tdesktop v 1.8.15. It works on the following OS just fine: I've also asked a question related to this issue: #6930 |
Hmm, this is odd. I have 1.8.15 right now, and there's no kinetic scrolling. Archlinux here. |
|
@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. |
|
@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. |
|
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. |
|
@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 |
|
@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:
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. |
|
@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). |
Am I reading it wrong? I see:
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 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 |
|
Okay, so, I crafted up a minimal example of using 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) |
|
@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 Debug code#include <QApplication>
#include <QLabel>
#include <QScrollArea>
#include <QScroller>
#include <QDebug>
#include <QMetaEnum>
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();
} |
|
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 |
|
Thanks, I totally believe that there's a Qt bug here. Nice job reporting it. |
|
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! |
|
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. |
|
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! |
|
Still relevant |
|
TDesktop 3.6.1x64 for Windows has Kinetic Scroll, |
|
https://odysee.com/@Dissent:c/tdesktop30fps:1 happens on both sides of Telegram, Telegram has very low Ram usage... Windows81x64 i recorded the video with an external HDMI PCIe recorder, and other PC. Control Panel Settings: browser.yandex is the most smooth scroll, but Not this: |
|
i have bad news... Kubuntu 20.10 Groovy Gorilla, Scroll jitter is insane... i know the GPU is inferior to Nvidia GT 730, Telegram Latest Edge version 3.6.2x64 https://en.wikipedia.org/wiki/Mac_Mini#Third_generation_(Unibody) i can recor a video if you want to cry. |
|
https://odysee.com/tdesktop30fps_1:dc5cbc0e0864de7da6fb11fd8f29a4a057928c9e i think i found the root of the problem... i changed to a Microsoft Wireless Mouse 5000 when moving slow, the stepness / staircase feeling can be detected visually, but smaller. in OSX the wheel has severe problems, after Sierra http://xahlee.info/kbd/mouse_dpi.html https://www.gearrate.com/en/guide/mouse-dpi/ |
|
found a better way to explain the problem.: mouse wheel lines are not pixels, with 1 setting i need to move very fast the mouse wheel to scroll the screen at an acceptable speed. Same happens with MIDI volume cc7, Smooth Volume algorithm, gradually change values same: FullHD has 1920x1080x30fps In Sony TVs is called MotionFlow, https://ru.wikipedia.org/wiki/Motionflow |
|
tested pearOS Monterrey in acer Aspire 5 Touchpad, each hardware scroll algorithm behaves differently. in linux there is Some softwares like Yandex & Firefox try to solve the HW differences problem, creating its own scroll algorithm. |
|
This issue is now a part of #25126 |
|
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. |
|
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 #6746 (comment) this becomes a huge task (and given the priorities, I tend to think this won't be ever implemented, sorry). |
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:
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. |
|
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. |
|
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. |
Hi-Angel
changed the title
|
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. |
|
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. |
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. |
|
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 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 |
|
@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. |
|
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). |
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. |
|
There was some related research for the stories UI implementation. Conclusions:
The Qt's wayland backend is also full of funny code such as: |
|
And macOS indeed the only platform having touch events produced by touchpad so the QScroller is relevant only for macOS touchpads apparently. |
|
so no hope to get this in a reasonably close future, not even on wayland? |
|
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. |
|
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. |
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). |
this is represented by pixelDelta and phase on QWheelEvent I guess |
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.
The text was updated successfully, but these errors were encountered: