Skip to content

Add per-app scroll source ignore option#939

Open
MahdiNazemi wants to merge 1 commit into
Caldis:masterfrom
MahdiNazemi:ignore-scroll-source-apps
Open

Add per-app scroll source ignore option#939
MahdiNazemi wants to merge 1 commit into
Caldis:masterfrom
MahdiNazemi:ignore-scroll-source-apps

Conversation

@MahdiNazemi
Copy link
Copy Markdown

Summary

  • Add a per-application setting to ignore scroll events emitted by selected apps.
  • Bypass Mos scroll handling before smoothing when the event source app is ignored.
  • Expose the option in the per-app scrolling popover and invalidate the source cache when settings change.

Testing

  • git diff --check
  • xcodebuild -scheme Profile -configuration Release -destination 'platform=macOS' -derivedDataPath /Users/mnazemi/Downloads/Mos-ignore-scroll-source-DerivedData CODE_SIGN_STYLE=Manual DEVELOPMENT_TEAM= CODE_SIGN_IDENTITY=- build

Allow per-application entries to bypass Mos scroll handling when the app itself emits a scroll event. This keeps keyboard scrollers from being smoothed or accelerated while preserving existing target-app settings.
@Caldis
Copy link
Copy Markdown
Owner

Caldis commented May 7, 2026

why we need this?

@MahdiNazemi
Copy link
Copy Markdown
Author

Applications that support keyboard-based scrolling (such as Homerow and Keyboard Scroller) generate scroll events that Mos intercepts, often resulting in excessive scrolling. Since these apps typically include their own smooth-scrolling functionality, using Mos alongside them can cause conflicts.

@Caldis
Copy link
Copy Markdown
Owner

Caldis commented May 9, 2026

Hi @MahdiNazemi , thanks for your explanation

This scenario seems uncommon, but the implementation strategy is correct. My consideration was to avoid increasing the performance overhead of the scrolling process with such rare use cases (the overhead of each if-else statement in the core scrolling module's pipeline is amplified).

The interactions and styles under Application pagination also need to be considered, since Target and Source are two different semantics.

If more users report similar issues, I will consider merging this MapReduce and further optimizing the UX

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants