Fixes#3072
Previously, when `window-theme = auto`, the appearance was delayed
enough on the DispatchQueue that the window was already visible. This
would result in the window appearing with the wrong appearance before
switching to the correct one.
For annoying reasons, we can't set the NSApplication.shared.appearance
in `applicationDidFinishLaunching` because it results in a deadlock with
AppKit.
This commit moves to set the `NSWindow.appearance` in `windowDidLoad`
(and any config sync) to ensure that the appearance is set before the
window is visible.
This is probably the right solution anyways because this allows windows
with different background colors to each have their own distinct
appearance.
## Description
Introduce a setting allowing to customize the behavior of the quick
terminal when it loses focus. By default, the quick terminal will
automatically hide. However, you can now configure it to remain open by
setting `quick-terminal-autohide: false`.
Resolves#2558
Introduce a setting allowing to customize the behavior of the quick terminal
when it loses focus. By default, the quick terminal will automatically hide.
However, you can now configure it to remain open by setting
`quick-terminal-autohide: false`.
Resolves#2558
Ghostty now has a release channel build configuration. Current valid
values are "tip" and "stable" but I imagine more will be added in the
future.
The release channel is inferred whether the version we specify with the
`-Dversion-string` build flag has a prerelease tag or not. If it does,
the release channel is "tip". If it doesn't, the release channel is
"stable".
This also adds a configuration to specify the release channel for
auto-updates for the macOS application.
Fixes#2516
Those changes mean that when we have one ghostty window in non-native
fullscreen and another ghostty window not in fullscreen switching to not
fullscreen window won't cause appearing menu bar and dock. I think it
looks good:
If we implement detection and make menu bar and dock appear for not
fullscreen window in this case it will cause the fullscreen window to
change its size and will look bad.
Non-native fullscreen works bad with multiple screens in either way.
E.g. switching to a non-native fullscreen window would cause menubar
disappering on another screen or switching to not fullscreen window
would show menu bar over fullscreen window on another screen. I think
nobody would want non-native fullscreen with multiple screens.
Fixes#2900
It's possible for moveFocus to infinite loop if the surface view we're
trying to move focus to NEVER gets attached to a window. This can happen
if the window is destroyed.
I think this issue should be more systemically fixed so it can't happen
but this workaround for now prevents moveFocus from being an infinite
loop source for the time being.
Fixes#2840
Related to #2842
This builds on #2842 by missing a key situation: when native fullscreen
is toggled using the menu bar items it doesn't go through our
`FullscreenStyle` machinery so we don't trigger fullscreen change
events.
This commit makes it so that our FullscreenStyle always listens for
native fullscreen change (even in non-native modes) to fire a fullscreen
did change event. This way we can always rely on the event to be fired
when fullscreen changes no matter what.
Fixes#2848
The proper way to convert a unicode scalar in Swift is to use the
`String` initializer that takes a `UnicodeScalar` as an argument. We
were converting a number to a string before, which is incorrect.
Fixes#2850
In native fullscreen, the titlebar container is no longer part of our
NSWindow and is instead a separate window called
NSToolbarFullScreenWindow. We now search for this window when we are in
native fullscreen.
The prior light/dark mode awareness work works on surface-level APIs. As
a result, configurations used at the app-level (such as split divider
colors, inactive split opacity, etc.) are not aware of the current theme
configurations and default to the "light" theme.
This commit adds APIs to specify app-level color scheme changes. This
changes the configuration for the app and sets the default conditional
state to use that new theme. This latter point makes it so that future
surfaces use the correct theme on load rather than requiring some apprt
event loop ticks. Some users have already reported a short "flicker" to
load the correct theme, so this should help alleviate that.
Previously, we would access the `ghostty.config` object from anywhere.
The issue with this is that memory lifetime access to the underlying
`ghostty_config_t` was messy. It was easy when the apprt owned every
reference but since automatic theme changes were implemented, this isn't
always true anymore.
To fix this, we move to the same pattern we use internally in the core
of ghostty: whenever the config changes, we handle an event, derive our
desired values out of the config (copy them), and then let the caller
free the config if they want to. This way, we can be sure that any
information we need from the config is always owned by us.
Fixes#2695
We had various issues with the pointerVisible property on macOS,
including the pointer not being hidden when it should be. Our only use
case today is mouse hide while typing so
NSCursor.setHiddenUntilMouseMoves is a better fit!
This allows us to enrich the build's commit property as a GitHub link.
This change also displays the property values using a monospaced font,
which I think looks a little nicer (especially the commit SHA).
