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.
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#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.
Related to #799
With tabbing mode disabled, fullscreen (native) windows when creating a
new tab creates a window in the tab bar, but ALSO puts the window into a
new "screen" on macOS. When you click the tab bar, macOS animates
between screens. Its jarring!
This commit makes it so that in fullscreen we go back to automatic
tabbing even for new windows, which produces new windows within a tab.
This is normal default behavior for macOS tabbed programs. When you are
not in fullscreen or exit fullscreen, then the tabbing mode returns to
disabled so Ghostty can manage it.
