Noticed that windows glitch when cascading: they show up in center of
screen, then quickly move to the correct position at last-cascade point.
This fixes the issue, by moving the `showWindow` call to _after_ the
setting of the last cascade point.
Now if you look at the code and think: "shouldn't this work without the
async-dispatch, like this?"
```swift
if (!window.styleMask.contains(.fullScreen)) {
Self.lastCascadePoint = window.cascadeTopLeft(from: Self.lastCascadePoint)
}
c.showWindow(self)
```
Then, yes, I had the same thought, but it doesn't. And as discussed on
Discord, we probably don't know what's going on behind the scenes.
So this is the simplified code of the version we have to live with:
async dispatching the cascade and non-cascade versions both.
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 prevents an unnecessary SurfaceView from being created. Creating a
SurfaceView is very expensive because this starts multiple threads,
creates the pty, starts the pty process, etc.
Additionally, this was exposing what I believe to be #497 when restoring
state: a surface view was created and destroyed very quickly causing
hangs on some machines. This still needs to be resolved but the behavior
in this commit was still a bug anyways.
Fixes#1052
This implements a `close_all_windows` binding in the core and implements
it for macOS specifically. This will ask for close confirmation if any
surface in any of the windows requires confirmation.
This is bound by default to option+shift+command+w to match Safari. The
binding is generall option+command+w but users may expect this to also
mean "Close All Other Tabs" which is the changed behavior if any tabs
are present in a standard macOS application. So I chose to follow Safari
instead.
This doesn't implement this feature for GTK, that's left as an exercise
for a contributor.
Fixes#1052
This implements the about window as a custom window with a view
controller. This lets us implement the proper responder chain so that
our custom close window IBActions do the right thing.
This has an additional benefit that we can easily customize this window
going forward.
Fixes#1018Fixes#1020
This disables the "visibleAtLaunch" configuration in the xib and
manually shows the window when it loads. This lets us carefully control
what happens particularly when a window is full screen (native) and part
of Mission Control.
Previously, the behavior depended on the Settings.app "Prefer tabs
when opening documents" setting, but we didn't handle every behavior
correctly (see #1018 and #1020). I couldn't find a way to robustly
handle all cases because there are no published macOS APIs for
interacting with Mission Control...
Plus, terminals aren't really "documents" so it did confuse at least one
user that Ghostty would follow this configuration. We just incidently
did because we use native tabbing.
This PR takes full control into our own hands. Our behavior is now:
- If a new window is created from a native fullscreen window, the
new window is created into native fullscreen.
- If a new tab is created from a native fullscreen window, the
tab is added to the existing window and does not create a new space.
- If a window or tab is created from a non-fullscreen window, the
existing behaviors remain.
Prior to this commit, the shortcut shown on the tab would not be updated
until a focus change occurred. There is no event for this so the way we
do it is by listening for the tab view frame to change, comparing the
window state, and then updating labels.
Related to #642Fixes#910
See #642 for why we want to ignore the "always" userTabbingPreference.
To do that, we'd set tabbingMode to "disallow" because we manually (in
code) handled it all.
Unfortunately, setting the tabbingMode to "disallow" introduce #910. I
still believe this is a macOS bug at heart, so I'm going to submit an
Apple Feedback item for it. However, I've found a workaround which I
also feel is the better solution, implemented here.
Instead of setting tabbingMode to "disallow" I now detect if we're in
the scenario where the user has their system tabbing preference set to
"always". In that case, we detect if the new window has been
automatically put into a tab group by macOS, and if so we remove it.
This all happens in the `windowDidLoad` controller callback. At this
phase, our Ghostty-managed windows should NEVER be in a tab group,
because "new tab" adds them to a tab _after_. So we can be certain that
if we're already in a tab group it was from the macOS system setting.
This happens to fix#910.
Instead of making a separate enum that must be translated from the
ClipboardRequest type, simply re-use ClipboardRequest to determine the
clipboard confirmation reason.
This tells AppKit to give the tab labels higher priority than the tab
titles. When the tabs become small, this causes the tab title text to be
truncated instead of dropping the tab label.
Fixes: https://github.com/mitchellh/ghostty/issues/843
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.
