This commit enables macOS dictation (triggered by pressing Fn twice) to work
in kitty by implementing the necessary accessibility methods.
The key fix is changing `selectedRange` to return `NSMakeRange(0, 0)` instead
of `kEmptyRange` (NSNotFound, 0). When selectedRange returns NSNotFound, macOS
dictation cannot determine where to insert text and fails silently.
Additional accessibility methods implemented:
- accessibilitySelectedTextRange: Returns cursor position for dictation
- accessibilityNumberOfCharacters: Returns 0 (terminal has no fixed buffer)
- accessibilityInsertionPointLineNumber: Returns 0
- accessibilityValue: Returns empty string
- setAccessibilityValue: Routes dictated text to keyboard input
This fix is inspired by the similar fix in Emacs v30 which restored dictation
by implementing selectedRange properly after migrating to NSTextInputClient.
Fixes: https://github.com/kovidgoyal/kitty/issues/3732
As is typical with Wayland, the protocol is poorly designed and
implemented even worse. Hyprland 0.53 has completely broken color
management.
https://github.com/hyprwm/Hyprland/discussions/12788
In addition it and mangowc crash when using color management with nouveau drivers.
https://github.com/kovidgoyal/kitty/issues/9030
KDE kwin does not support the sRGB transfer function. And the geniuses
at Wayland are any way planning to deprecate sRGB as a transfer function.
Only GNOME mutter seems to get it right.
Then there are people that are likely going to shoehorn this into EGL
instead of leaving it under application control via the protocol anyway.
https://github.com/KhronosGroup/EGL-Registry/issues/197
Sigh. Wayland.
This does not match X11/macOS behavior. And I see no logical reason why
it should be so. The wheel_scroll_multiplier should be used to adjust
this by end users.
On compositors that support compositor key repeat events, use those, for
complete robustness. Sadly no actual compositor implements these yet.
Otherwise use a timer fd/pipe to queue the repeat events and only
dispatch them after events from the compositor are handled. This means
release events from the compositor will prevent spurious repeat events.
One can, in the worst case lose some repeat events if there is a very
large interval between the start of the timer and the next poll, but
that is unavoidable and is why repeat events should come from the compositor
in the first place.
Fixes#9224
Far more robust. Sadly no actual compositors yet support this. Fifteen
years it takes Wayland developers to correct their most basic mistakes.
See #9224
The locks were not being initialized, and since I was there did some
general cleanup as well, moved the locks array into displayLinks rather
than having another global namespaced variable.
