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
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.
Apparently on some systems Tahoe sends a resize event on wake from
sleep/lid open for obscure reasons and then proceeds to crash if one
redraws during that event. Sigh.
This is nicer now every OS Windows doesnt cause a notification. Also
fixes#9034 which was caused by us setting an explicit appearance on the
window when the titlebar is set to a specific color thereby preventing
the views in the window from getting appearance change notifications.
There were two issues.
1) Setting window background color to a non-zero opacity causes
darkening (essentially there were two layers of blending)
2) The titlebar background view could end up in the wrong position
because it was a child of the content view rather than its super view
Fix both issues setting the window background to clear color and
moving the background view into the super view while making sure it is
positioned correctly using explicit constraints. Phew.
This reverts commit d837a64e36.
Commit 24b31d96e9 fixes the original
problem of "ghost windows" that d837a64 was trying to solve. (I have no
idea how or why it does.)
One side-effect of the workaround from d837a64 is that it causes closed
windows to be moved to the (0,0) before being destroyed. This means that
when creating new windows, they are placed on the left-most display,
instead of the display in which the previously closed window was on as
you would expect. Reverting this kludge fixes this bug.
Dont redraw an OSWindow during a resize event if the resize event is
accompanied by a screen change as it causes a crash in macOS OpenGL
driver. Fixes#8983
