I think I am going to rewrite the API to integrate with the event loop,
now that I have a good handle on the semantics of DnD in the two major
platforms.
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.
