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.
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.
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#2519
This sets up the colorspace for terminal windows in the base controller.
This also modifies some of our logic so its easier for subclasses of
base controllers to specify custom logic when the configuration reloads,
since that's likely to be a common thing.
Fixes#2462
This sets up a listener for screen parameter changes. This only triggers
when a screen is added, removed, or a parameter such as its resolution
changes. This doesn't trigger when a window is simply moved from one
screen to another.
On parameter change, we ensure that the window is within the bounds of
the screen. As an exception, if the window was previously already
outside the bounds of the screen, we don't move it back in.
Fixes#2330
The quick terminal now supports fullscreen. The fullscreen mode is
always non-native due to the quick terminal being a titleless, floating
window.
When the quick terminal loses focus and animates out, it will always
exit fullscreen mode.
First, this commit modifies libghostty to use a single unified action
dispatch system based on a tagged union versus the one-off callback
system that was previously in place. This change simplifies the code on
both the core and consumer sides of the library. Importantly, as we
introduce new actions, we can now maintain ABI compatibility so long as
our union size does not change (something I don't promise yet).
Second, this moves a lot more of the functions call on a surface into
the action system. This affects all apprts and continues the previous
work of introducing a more unified API for optional surface features.
This was breaking various other features:
- Popovers stopped working
- Split divider drag gestures stopped working
For now we document the top part of the window is draggable... we
can look into removing that limitation later.
Fixes#1833
This is an attempt to simplify the logic that has organically grown
convoluted over time with regards to how the titlebar and tab bar is
styled.
This field is one unified field that ONLY addresses titlebar and tab bar
styling. It can be one of "native", "transparent", or "tabs". The
"native" field is the new behavior in this commit: it makes the titlebar
and tab bar appearance be absolutely native. We do not color anything
(if we do its a bug).
The "transparent" option is the previous `macos-titlebar-tabs = false`
setting where the titlebar/tab bar is native but colored according to
the window background color.
The "tabs" option is `macos-titlebar-tabs = true`.
The `window-theme = auto` affect on titlebar appearance has been
removed. Now, the titlebar will NEVER be styled with "native" and MAY be
styled with "transparent" and will ALWAYS be styled with "tabs" (since
that's a totally custom look anyways).
Fixes#1771
I'm not convinced this fix won't regress some other behavior, but in my
titlebar tab and native tab modes with and without transparency, this
has looked okay to me.
I make the following suggestion through a PR since I already tried this locally and have a branch ready:
- Rename Split Horizontally to Split Right
- Rename Split Vertically to Split Down
Rationale:
The terms horizontal and vertical are ambiguous in the context of splitting (does it mean the splitter is vertical, or are the panes organized vertically?)
Different apps pick different interpretations, so people get confused.
IntelliJ made the same change as above based on user feedback: https://youtrack.jetbrains.com/issue/IJPL-130991/Split-Vertically-and-Split-Horizontally-are-ambiguous-and-should-be-renamed
Ghostty is using the left/right nomenclature in other menu items. In the codebase, SplitDirection is already left/right.
Add support for configurable fonts for window and tab titles. This is
only implemented for macOS (and could be macOS-only if other platforms
aren't able to support this using their windowing toolkits). It plays
nicely with regular and titlebar tabs.
To do this I forced a toolbar, so that we would have a place to put the
button when no tabs were opened. I also took the opportunity to make the
standard title/tab bar meld better with the terminal's background color,
just as we do with titlebar tabs.
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.
FAR from a perfect fix, as the background seen through the tabs during window drags will be behind by a frame or so still, but definitely a vast improvement over not updating at all.
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.
Zein Hajj-Ali