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.
❤️👻
This is the icon that we'll launch Ghostty 1.0 with. It was designed by
Michael Flareup at PixelResort. It retains the style of the original
Ghostty icon by Alasdair Monk, but brings in the new Ghost character and
adds details that make it more Apple-like.
The new Ghost character is an important evolution from the original
since it separates us from looking too much like PacMan. The new Ghost
is more unique and recognizable to Ghostty (or, hopefully will be!).
The icon itself has more details: the aluminum around the edge has
texture for the large enough sizes, there are visible scanlines, the
glow of a screen emanates from the ghost.
The icon itself is stylistic more Apple-like than other platforms. I
think Apple icons tend to look very good in more environments than the
reverse and I'm a big fan of the Apple aesthetic so I wanted to bring
that to Ghostty for all platforms.
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.
I genuinely don't know what they do, but Xcode recommended it and
cursory docs reading seems to indicate its safe. I don't think it'll
result in any noticeable changes.
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.
This enables the compile options and Xcode configuration so that logging
in Metal shaders shows up in our Xcode debug console. This doesn't add
any log messages, but makes it so that when we iterate on the shaders in
the future, we can add and see logs to help us out.
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).
The bug: ctrl+shift+enter on macOS 15 shows a context menu and doesn't
encode to the terminal.
This avoids a system-wide keybind that shows a context menu in macOS
15+. In general Ghostty doesn't try to override system-wide keybinds
but this one is particularly annoying and not useful to terminal users.
We've discussed making this logic configurable for all system level
keybinds but for now this is a quick fix specifically for
ctrl+shift+enter.
Fixes#2565
This appears to be a bug in macOS 15. Specifically on macOS 15 when the
new native window snapping feature is used, `cascadeTopLeft(from: zero)`
will move the window frame back to its prior unsnapped position.
The docs for `cascadeTopLeft(from:)` explicitly say:
> When NSZeroPoint, the window is not moved, except as needed to constrain
> to the visible screen
This is not the behavior we are seeing on macOS 15. The window is on the
visible screen, we're using NSZeroPoint, and yet the window is still
being moved. This does not happen on macOS 14 (but its hard to say
exactly because macOS 14 didn't have window snapping).
This commit works around the issue by saving the window frame before
calling `cascadeTopLeft(from: zero)` and then restoring it afterwards
if it has changed.
I've also filed a radar with Apple for this issue.
