Open cholick opened 3 weeks ago
It would be interesting to test this in the latest 4.4 nightly builds (https://musescore.org/en/nightly-builds). Those use a newer version of Qt, which supposedly improves some things around scrolling.
It does behave the same in nightly (MuseScore Studio version (64-bit): 4.4.0-242310503, revision: github-musescore-musescore-bf636e6
)
That's regrettable. Then the problem that was fixed must have been something else. The thing is that for all scrollviews except the score view, we fully depend on the functionality that Qt offers. I've done some searching on the internet, and it looks like there is really no way to disable the smooth scrolling. I found an issue about it at the Qt issue tracker, that doesn't give a lot of hope: https://bugreports.qt.io/browse/QTBUG-83843. Reported years ago, but no solution. One day, we might consider patching Qt ourselves, but I'm not sure how feasible that is.
Thanks for digging in on that! I'd hoped it was just a flag you folks could pass through to Qt.
Issue type
UX/Interaction bug (incorrect behaviour)
Description with steps to reproduce
Supporting files, videos and screenshots
https://github.com/user-attachments/assets/918a6f02-feb6-44f5-9224-c84b7b533062
What is the latest version of MuseScore Studio where this issue is present?
4.3.2-241630832, revision: github-musescore-musescore-22b46f2
Regression
No.
Operating system
macOS 14.6, Arch.: x86_64
Additional context
I've included Chrome and a directory to show that step-wise scrolling is the expected behavior. I'm someone who strongly dislikes smooth scrolling, and have it disabled in applications that implement their own scrolling behavior outside of the operating system. The palette both scrolls smoothly and seems to be at a slightly different speed, behaving different from everything else on my computer, so the bug in my mind is how the palette has implemented vertical scrolling.
Checklist