Scrolling goes too fast/does not stop

[fryorcraken]

Bug Report

Description

When scrolling with a touchpad the list of chats. The scrolling takes a bit too long to stop once fingers have stopped moving/off the touchpad.

Steps to reproduce

• put mouse pointed over chat list
• scroll
• stop scrolling

Expected behavior

• Stop fast so the right chat can be selected

Actual behavior

• it keeps on going making it difficult to select right chat

Additional Information

• Status desktop version: 0.8.0
• Operating System: Liux Fedora

https://user-images.githubusercontent.com/110212804/205773419-52d5d5f5-1737-4186-9d2f-8a0573d64e12.mp4

[fryorcraken]

note similar issue in the chat window itself.

[fryorcraken]

I'd say this should be high prio, makes it barely usable for me as I just can stop at the right to read a message, select a channel or select a contact.

Note that I am using an Apple magic touchpad with my Fedora Linux. Scrolling is fine in my other apps (Discord, etc).

[Menduist]

Same for me, native XPS touchpad on Arch.

Basically:

• The scrolling speed has no impact (if I scroll faster or slower on my trackpad, the scroll still happens at the same speed)
• There is some weird inertia when stopping the scrolling

The combination of the two makes it really hard to scroll properly, I resort to moving the scrollback manually or Ctrl-K for chats

[fryorcraken]

Today I have noticed that the scrolling in the chat window is very jumpy:

https://user-images.githubusercontent.com/110212804/206083187-6ddef0ab-f1f2-47ca-a244-e38b40754726.mp4

It's sticky in the way that it scroll down and then jump back up and so you basically end up not scrolling at all (trying to go down to see more recent messages).

This is after scrolling up for a while to look for my last message.

[0x-r4bbit]

I have the same issue (Dell XPS, Ubuntu) using the trackpad. I think we use a custom scrollbar (@MishkaRogachev ?) so maybe there's something we can do?

[caybro]

This is related to Qt not supporting well those high precision (high DPI) mice and trackpads... Not much we can do about this except waiting for the Qt 5.15 transition (should happen soon hopefully).

[Menduist]

When building master from source, everything I described is still valid, but the max scrolling speed is a lot slower, so it's manageable. Not sure if it's because it's master, or because I built using a random QT version

[caybro]

When building master from source, everything I described is still valid, but the max scrolling speed is a lot slower, so it's manageable. Not sure if it's because it's master, or because I built using a random QT version

Likely the Qt version... what is it that you used? :)

[Menduist]

https://archlinux.org/packages/extra/x86_64/qt5-base/ so 5.15.7 apparently

[caybro]

https://archlinux.org/packages/extra/x86_64/qt5-base/ so 5.15.7 apparently

Good to know it helps 😉 @iurimatias

[Menduist]

Setting this in every flickable:

    maximumFlickVelocity: 1000000
    flickDeceleration: 1000000

Make the app behave like any other app on my PC: almost no weird inertia, and I can control the speed since I'm not capped by "maximumFlickVelocity"

EDIT: my guess for the "jumpy chats" is that once the message are out of view, you don't render them somehow? And so they don't take the same vertical space (especially visible for images etc). When they come back to view, they take all the space again, and things become weird

[MishkaRogachev]

Setting this in every flickable:

    maximumFlickVelocity: 1000000
    flickDeceleration: 1000000

Make the app behave like any other app on my PC: almost no weird inertia, and I can control the speed since I'm not capped by "maximumFlickVelocity"

EDIT: my guess for the "jumpy chats" is that once the message are out of view, you don't render them somehow? And so they don't take the same vertical space (especially visible for images etc). When they come back to view, they take all the space again, and things become weird

For some components we've done workaround with maximumFlickVelocity and synchronousDrag:
https://github.com/status-im/status-desktop/blob/master/ui/StatusQ/src/StatusQ/Core/StatusScrollView.qml https://github.com/status-im/status-desktop/blob/master/ui/StatusQ/src/StatusQ/Core/StatusListView.qml

[caybro]

EDIT: my guess for the "jumpy chats" is that once the message are out of view, you don't render them somehow? And so they don't take the same vertical space (especially visible for images etc). When they come back to view, they take all the space again, and things become weird

Good observation, yes :)

[Menduist]

For some components we've done workaround with maximumFlickVelocity and synchronousDrag:

Not sure what synchronousDrag does, but, maximumFlickVelocity set to 2000 is part of the issue:

The scrolling speed has no impact (if I scroll faster or slower on my trackpad, the scroll still happens at the same speed)

This is because I'm hitting the limit too fast when scrolling (2000 is quite slow on my setup, I can go easily faster than this with my trackpad, apparently these values are system dependent? idk)

[iurimatias]

duplicate of https://github.com/status-im/status-desktop/issues/3353

[alexandraB99]

waiting to see if https://github.com/status-im/status-desktop/issues/8642 solves or improves things

[iurimatias]

closing as a duplicate of https://github.com/status-im/status-desktop/issues/3353