Fixes#1330
I admit this code is a mess to understand, so I'm not 100% certain this
fix is correct. It definitely fixes#1330 but I'm not sure if this
breaks other split scenarios.
I believe that our logic here was simply wrong, notice that left/right
had opposite logic and this brings it all into consistency.
Long term, we should redo all of our directional movement since we've
refactored how split state is stored now on the controller with parent
references.
This allows for example clicking on a split when focused on a different
app and having focus immediately jump to that split. Before this, you'd
have to click to focus the window, then second click to focus on the
split.
Fixes#1214
This introduces the `window-colorspace` configuration which allows
configuring the colorspace to use for windows on macOS. The default is
sRGB (same as before) but this can also be set to `display-p3`.
Fixes#1227Fixes#1206
This moves the logic that respects `window-width` and `window-height` to
the controller window initialization. This is where it should've been
all the time but we previously didn't use a controller architecture so
we did our best to use heuristics in the view to do this.
This location now ensures that this only happens on window
initialization and only if we have one surface.
This adds middle-click support to MacOS.
Very simple update, since everything else is in place to handle mouse
clicks in the embedded runtime already, we just needed to add the event
handlers in the UI.
Related to https://github.com/mitchellh/ghostty/issues/1082
This fixes two separate issues to follow along with the new spec changes
Kovid pushed to Kitty:
1. When two modifiers are pressed and one is released, this shows up
as a proper release event with the correct side. Previously, the
correct side was shown but as a press event.
2. When two modifiers are pressed and one is released, the Kitty event
should not have that specific modifier set. For example, pressing
left ctrl, then right ctrl, then releasing right ctrl should encode
as "right ctrl released" but with NO modifiers still present.
Some control key combinations must be handled specially by Ghostty to
prevent undesirable behavior at the OS level. For now, this includes
only Ctrl-/, which makes a "beep" sound when processed by AppKit. It is
unclear why this beep occurs and no answer was found after extensive
searching.
This solution is inspired by iTerm2, which also handles certain control
key combinations (including C-/) manually before passing them on to
Cocoa/AppKit.
The return value of takeUnretainedValue() is non-optional, so this
function was never _actually_ returning an optional value, so the guard
clauses sprinkled throughout were unnecessary.
