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.
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#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.
This was recently introduced a few days ago. Unfortunately, this doesn't
work as expected. The "function" modifier is not actually the fn key
but used by macOS to represent a variety of "functional" key presses.
This breaks other bindings such as #2411.
I can't find a source on the internet that reliably tells me how we
can detect fn key presses, but I do find a number of sources that tell
us we can't.
This also slightly changes the code, as the duplication of the for loop
was making it harder to read now. I think technically slightly less
efficient, but this is hardly a hot code path, so should be fine imo.
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.
Fixes#1656
When called as part of window restoration AppKit has a lock, so
NSAppearance changes need to be called async.
See deadlock:
```
Thread 1 Queue : com.apple.main-thread (serial)
0 0x000000018fd63fac in __ulock_wait ()
1 0x00000001069bf720 in _dlock_wait ()
2 0x00000001069bfaec in _dispatch_group_wait_slow ()
3 0x0000000106b5f5c4 in interposed_dispatch_group_wait ()
4 0x00000001937fb1f0 in NSCGSTransactionRunPreCommitActions_ ()
5 0x00000001938f1230 in -[_NSCGSTransaction synchronize] ()
6 0x00000001938f11ac in NSCGSTransactionSynchronize ()
7 0x000000019382ad30 in +[NSCGSWindow(NSCGSSpace) isAnyWindowOnAVisibleSpace:] ()
8 0x000000019382a968 in -[NSWindow _isInSomeVisibleSpace] ()
9 0x000000019382a8e4 in -[NSWindow isOnActiveSpace] ()
10 0x0000000193db8d98 in -[NSApplication(NSApplicationAppearance_Internal) _invalidateWindowAppearances] ()
11 0x00000001938f44d4 in -[NSApplication(NSAppearanceCustomization) setAppearance:] ()
12 0x0000000102c48050 in AppDelegate.syncAppearance() at /Users/mitchellh/code/go/src/github.com/mitchellh/ghostty/macos/Sources/App/macOS/AppDelegate.swift:412
13 0x0000000102c47840 in AppDelegate.configDidReload(_:) at /Users/mitchellh/code/go/src/github.com/mitchellh/ghostty/macos/Sources/App/macOS/AppDelegate.swift:380
14 0x0000000102c43c7c in AppDelegate.applicationDidFinishLaunching(_:) at /Users/mitchellh/code/go/src/github.com/mitchellh/ghostty/macos/Sources/App/macOS/AppDelegate.swift:110
```
Fixes#1389
This is just a fun AppKit quirk. This menu item is set automatically
based on the keyboard shortcut (apparently) and when its overwritten
then its gone forever. So, let's just not set it.
