Apparently when running under XWayland, we cant rely on libinput to
detect highres scroll devices. Sigh. Linux input is such a disaster.
Dunno if this will break something else, hopefully not.
Fixes#9649
Implements drag-to-reorder for window title bars, following up on the
merged window title bar feature (#9450) and the design discussion in #9619.
- Drag a title bar and drop on another title bar to swap positions
- Drop on a window body quadrant (left/right/top/bottom) to insert as
a directional split; Splits layout uses insert_window_next_to(), other
layouts fall back to move_window_to_group()
- Drop on a tab bar tab to move the window into that tab
- Drop on another OS window to move into its active tab
- Drop outside kitty to detach into a new OS window
- Tab bar highlights the hovered tab during a window drag, mirroring
how the destination window title bar is highlighted
- toggle_window_title_bars action temporarily force-shows title bars
for drag-to-reorder when they are normally hidden, auto-hiding after
the drag completes
- window_title_bar_drag_threshold option (default 5px) controls how far
the mouse must move before a drag is initiated; 0 disables dragging
MIME type follows the same convention as tab dragging:
application/net.kovidgoyal.kitty-window-{PID}
Ref: #9619
Tools like Easy Move+Resize use the macOS Accessibility API to find and
move/resize windows. They call AXUIElementCopyElementAtPosition to get the
content view, then use kAXWindowAttribute to navigate to the parent window.
The isAccessibilitySelectorAllowed: whitelist was blocking these selectors,
preventing external window management tools (Easy Move+Resize) from working with
kitty.
Fixes#5561
Hide the CSD titlebar subsurface while keeping shadow borders for
resizing. On SSD compositors (GNOME), forces CSD mode to draw
kitty's own shadows without a titlebar.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
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.
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.
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
Now NSWindow::close no longer actually closes the window. Sigh. Have to
also set its frame to zero size, otherwise an invisible rect remains
that intercepts mouse events and takes up space in Mission Control.
Life is too short for this shit. Fixes#8952
