| Summary: | Mac OS Trackpad scroll buggy | ||
|---|---|---|---|
| Product: | [Applications] kate | Reporter: | axcelia |
| Component: | application | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | christoph, damian.adrian24, zkogdxdkur |
| Priority: | NOR | ||
| Version: | 21.08.1 | ||
| Target Milestone: | --- | ||
| Platform: | macOS (DMG) | ||
| OS: | macOS | ||
| Latest Commit: | https://invent.kde.org/frameworks/ktexteditor/commit/45258cb05e3af44b6c2e2e214f46d4f52cae4e88 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
Screen recording of the issue.
repro #2 log repro #2 screen recording repro #3 timeline full repro #3 log |
||
Created attachment 141761 [details]
repro #2 log
Generated with:
QT_LOGGING_RULES="*=true" /Applications/kate\ 2.app/Contents/MacOS/kate CHANGES.rst 2>&1 | ts -s '%.S' > kate.log
and then scrolling for about 10 seconds.
Created attachment 141762 [details]
repro #2 screen recording
Kate on the left, Thonny on the right (for comparison).
In each of them, I scroll down 3 times and then up 3 times.
I am able to reproduce this as well. Please let me know if you need additional data (I don't know about Qt / KDE to debug this further). IMHO, the importance should be higher; at least for me, this makes using Kate almost impossible. Thank you! --- VERSIONS macOS 10.15.7 Kate 21.08.1 (from kate-21.08.1-1348-macos-64-clang.dmg) KDE Frameworks 5.86.0 Qt 5.15.2 (built against 5.15.2) The only enabled plugins were Search & Replace and Text Filter. --- Attached "repro #2 log" and "repro #2 screen recording"; the log was generated by scrolling up and down a few times in a Kate window started with: QT_LOGGING_RULES="*=true" /Applications/kate\ 2.app/Contents/MacOS/kate CHANGES.rst 2>&1 | ts -s '%.S' > kate.log --- A version from ~March 2021 did not have this issue; unfortunately I replaced the installation and don't know the exact version. Trying to get that back, I managed to get a 21.04.3 version to build successfully with Craft; this version still has the scrolling issue: Kate 21.04.3 KDE Frameworks 5.83.0 Qt 5.15.2 (built against 5.15.2) I couldn't get a successful build with versions earlier than this. --- This Reddit thread seems to describe the same issue: https://www.reddit.com/r/kde/comments/p8byi9/kate_scrolling_problem_on_mac/ I just wanted to add something I thought was worth mentioning since I've been fighting with this issue for a week or so. When I'm seeing the problem it's almost like it's trying to imitate the default natural scroll on the mac. I have natural scroll switched off because I'm used to scrolling the other way but I was wondering if somewhere it's assuming Natural scroll should be switched on so it's scrolling the wrong way initially. Created attachment 141991 [details]
repro #3 timeline full
Created attachment 141992 [details]
repro #3 log
Based on some log combing, I reached this hypothesis:
The scroll stutter happens because "NSEvent: type=ScrollWheel" events either stop being emmited or stop being processed, and a second-long gesture is started and keeps being updated as I keep moving my fingers on the trackpad a second time.
I can't tell if the gesture starts because ScrollWheel NSEvents stop happening, OR if the gesture being started prevents the ScrollWheel events in the first place.
Next things I plan to do to narrow this further (any suggestions are *highly* appreciated, since I'm really out of my depth here):
* disable gestures (if possible), and see if the stutter still happens
* search for Qt bugs having to do with gestures and scrolling / mouse events
---
I obtained the log by starting Kate at the end of a file that's ~2k lines long, and scrolling up a few times (details on the log below).
Timeline (seconds since app start, matching the log output):
* ~6 start scrolling
* ~6.8 scroll starts happening on screen
* 6.29 .. 8.58 (repeating every ~.01s, interleaved in various ways)
QGestureManager:Recognizer: ignored the event:
Sending NSEvent: type=ScrollWheel
Qt::ScrollUpdate
Sending NSEvent: type=Gesture
touchesMovedWithEvent
Qt::ScrollMomentum
* 8.58 these stop appearing as frequently
Qt::ScrollUpdate
Sending NSEvent: type=ScrollWheel
Qt::ScrollMomentum
type=Gesture, touchesMovedWithEvent and "ignored the event" keep appearing
* ~8.6 scroll stutters visibly (it's likely at this point I've lifted my fingers off the trackpad and and put them down again to start scrolling a second time)
* ~10.1 scroll stutters visibly (same as above)
* 10.41 "QGestureManager:Recognizer: maybe gesture"
touchesEndedWithEvent
QGestureManager:Recognizer: not gesture:
touchesBeganWithEvent
QGestureManager:Recognizer: maybe gesture:
QGestureManager::filterEventThroughContexts:
started gesture was delivered and accepted by KateViewInternal(0x7f85d9be3660)
* 10.46 (repeated until 13.07) "QGestureManager:Recognizer: gesture triggered"
QGestureManager::deliverEvents: sending to KateViewInternal(0x7f85d9be3660) gestures:
touchesMovedWithEvent
QGestureManager:Recognizer: gesture triggered:
QGestureManager::filterEventThroughContexts:
triggered: QSet(Custom gesture(state=GestureUpdated,hotSpot=...,type=Qt::GestureType(258)))
QGestureManager::deliverEvents:
(every other 5-10 of the above)
QGestureManager: we were asked to consume the event:
(very few; ~8 during 10, 2 during 11, 1 during 12)
Qt::ScrollUpdate
* ~11.1 scroll stops entirely
* 13:07
(first time after 10.41)
Sending NSEvent: type=ScrollWheel
Qt::ScrollEnd
touchesEndedWithEvent
---
"repro #3 timeline full" has a more complete timeline.
"repro #3 log" has the full log, obtained with:
QT_LOGGING_RULES="*=true" \
/Applications/kate\ 2.app/Contents/MacOS/kate ~/tomatoes.md 2>&1 \
| ts -s '%.S' \
| grep -Ev \
-e qt.widgets.painting \
-e qt.qpa.backingstore \
-e kf.texteditor \
-e kf.sonnet. \
| tee ~/Desktop/repro-3.log
The Kate used was kate-21.08.1-1354-macos-64-clang.dmg (KDE Frameworks 5.86.0,
Qt 5.15.2 (built against 5.15.2)).
OK, I think I managed to narrow down the issue to these two commits. Reverting them makes the scroll stutter / stop (while still two-finger scrolling on the trackpad) go away. https://invent.kde.org/frameworks/ktexteditor/-/commit/8f8be67ccf5b151d4c6cc570229fe4fbe28e76b3 "Add basic touchscreen support" https://invent.kde.org/frameworks/ktexteditor/-/commit/aa757c80e6ce8efee288c58154998d4e8e0f0dde "Use Okular's QScroller settings" I used the latest versions of libraries: kde/applications/kate : 21.08.1 kde/frameworks/tier3/ktexteditor : 5.86.0 I don't really know how to fix this, other than reverting the two commits (but that would remove touchscreen support). Is reverting OK? For now I'll keep using my own build. --- For anyone that's affected by this, here's how to make your own build: * Install Craft: https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Mac#Installation_using_Craft (commands below assume the default ~/CraftRoot path was used). * AFAICT, this "installs" the two packages (kate uses ktexteditor) in a way that allows the sources to be edited (at ~/CraftRoot/build/$full_package_name/work/$package-$version). craft -i --no-cache kate ktexteditor * Remove the lines added in the two commits above from these files: ~/CraftRoot/build/kde/frameworks/tier3/ktexteditor/work/ktexteditor-5.86.0/src/view/kateviewinternal.cpp ~/CraftRoot/build/kde/frameworks/tier3/ktexteditor/work/ktexteditor-5.86.0/src/view/kateviewinternal.h The versions may vary, you can go to the directory that contains src/ by doing "cs ktexteditor". * Compile the changes and create an installer: craft --compile --install --qmerge ktexteditor kate && craft --package kate The path to a .dmg should be output at the end; should be something like: ~/CraftRoot/tmp/kate-21.08.1-macos-64-clang.dmg Just reverting won't be a good idea, that will break the stuff we added this commits for. As one seems to be taken from Okular, does Okular have the same issues? I currently can't test Okular, since I can't get it to build: * I've tried building it twice, but it fails during `craft package` with "don't know how to handle otool -L output", and I'm not sure how to fix this. * Running ./build/kde/applications/okular/archive/Applications/KDE/okular.app/Contents/MacOS/okular fails too (no window shows), likely because `package` didn't finish (this works for Kate after `package` finishes successfully). * The Jenkins builds seem to be failing as well, but with a different(?) error: https://binary-factory.kde.org/view/MacOS/job/Okular_Release_macos/ If there's a way to run stuff from /build/kde/applications/okular/... on MacOS without `package` doing its thing, please let me know (I've struggled with finding a LD_LIBRARY_PATH equivalent on MacOS in the past, and that's what `package` seems to be doing). I think some dependency is missing, as e.g. libKF5Pty is not found (at least if I read the fail right). I could take a look. Git commit 005c41914edd500bd86b7365af456eec1f7016da by Christoph Cullmann. Committed on 07/10/2021 at 19:38. Pushed by cullmann into branch 'master'. add kpty, macOS compiles fails because it is missing M +2 -1 kde/applications/okular/okular.py https://invent.kde.org/packaging/craft-blueprints-kde/commit/005c41914edd500bd86b7365af456eec1f7016da macOS Okular should build again: https://binary-factory.kde.org/view/MacOS/job/Okular_Release_macos/758/console Thank you, Christoph! Unfortunately, the successful build of Okular (okular-21.08.2-758-macos-64-clang.dmg) fails to start on my Mac; the icon appears in the dock, but then nothing happens (there's no output on the terminal). I've noticed this happens for Kate too when running: ~/CraftRoot/build/kde/applications/kate/image-RelWithDebInfo-21.08.1/Applications/KDE/kate.app/Contents/MacOS/kate (hangs) but not when running: ~/CraftRoot/build/kde/applications/kate/archive/Applications/KDE/kate.app/Contents/MacOS/kate (starts OK, likely generated by "craft --package") Since "craft --package" seems to be fixing the RPATH of binaries, I suspect the Okular packaging script isn't fixing all of them (this is just a guess, though). *** Bug 450678 has been marked as a duplicate of this bug. *** A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/295 Git commit 45258cb05e3af44b6c2e2e214f46d4f52cae4e88 by Georg Gadinger. Committed on 23/02/2022 at 21:45. Pushed by cullmann into branch 'master'. view: fix buggy scrolling on macOS On macOS the trackpad also emits touch events which are sometimes picked up by the flick gesture recogniser registered by QScroller; this results in some odd scrolling behaviour as described in bug 442060. Therefore it's better to not let the QScroller register it on that platform. M +6 -0 src/view/kateviewinternal.cpp https://invent.kde.org/frameworks/ktexteditor/commit/45258cb05e3af44b6c2e2e214f46d4f52cae4e88 |
Created attachment 141322 [details] Screen recording of the issue. SUMMARY When you try to scroll using the trackpad on a MacBook Pro it responds erraticaly. Sometimes it tries to scroll back up when you are scrolling down and jumps about or tries to scroll back down when you are scrolling up and jumps around. It's ok if you hover over the overview and scroll, it only seems to be an issue in the main editor screen. STEPS TO REPRODUCE 1. Open any file that requires you to scroll 2. Try and scroll up and down a few times using the inbuilt trackpad 3. OBSERVED RESULT Scrolling is erratic and jumps about. EXPECTED RESULT Smooth scrolling that goes in the correct direction. SOFTWARE/OS VERSIONS macOS: OS X 10.15.7 ADDITIONAL INFORMATION I've attached a screen recording of the issue. I'm trying to scroll back up in the video but it keeps flicking back down until suddenly overshooting right to the very top.