Fixes#1500
This overhauls how we do focus management for surfaces to make it more
robust. This DID somehow all work before but was always brittle and was
a sketchy play with SwiftUI/AppKit behavior across macOS versions.
The new approach uses our window controller and terminal delegate
system to disseminate focus information whenever any surface changes
focus. This ensures that only ONE surface ever has focus in libghostty
because the controller ensures it is widely distributed.
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#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.
This enables shifted alt-prefixed keys, such as `shift+alt+.` on
US standard becoming `M->`. To do this, we needed to fix a few bugs:
(1) translation mods should strip alt even if other mods are set
(2) AppKit translation event needs to construct new characters with
the translation mods.
(3) Alt-prefix handling in KeyEncoder needs to allow ASCII utf8
translations even for macOS.
Fixes#872
In #867 we fixed macos-option-as-alt, but unfortunately AppKit ALSO does
some translation so some behaviors were not working correctly.
Specifically, when you had macos-option-as-alt set, option+e would
properly send `esc+e` to the pty but it would ALSO set the dead key
state for "`" since AppKit was still translating the option key.
This commit introduces a function to strip alt when necessary from the
translation modifiers used at the AppKit layer, preventing this
behavior.
This is a small cleanup change. This provides the Ghostty.AppState
object to any view that needs it within the TerminalSplit view hierarchy
without needing to explicitly define EnvironmentKeys.
This commit does two things: adds a weak reference to the parent
container of each SplitNode.Container and SplitNode.Leaf and moves the
"direction" of a split out of the SplitNode enum and into the
SplitNode.Container struct as a field.
Both changes are required for supporting split resizing. A reference to
the parent in each leaf and split container is needed in order to
traverse upwards through the split tree. If the focused split is not
part of a container that is split along the direction that was requested
to be resized, then we instead try and resize the parent. If the parent
is split along the requested direction, then it is resized
appropriately; otherwise, repeat until the root of the tree is reached.
The direction is needed inside the SplitNode.Container object itself so
that the container knows whether or not it is able to resize itself in
the direction requested by the user. Once the split direction was moved
inside of SplitNode.Container, it became redundant to also have it as
part of the SplitNode enum, so this simplifies things.
The resizeIncrements property is only modified when the cell size of the
focused window changes. If two splits have the same cell size then the
property is not modified when focusing between the two splits.
