When unset, we use Sparkle's default behavior, which is based on the
user's preference stored in the standard user defaults.
The rest of the previous behavior is preserved:
- When SUEnableAutomaticChecks is explicitly false, auto-updates are
disabled.
- When 'auto-update' is set, use its value to set Sparkle's auto-update
behavior.
Fixes#4433
When unset, we use Sparkle's default behavior, which is based on the
user's preference stored in the standard user defaults.
The rest of the previous behavior is preserved:
- When SUEnableAutomaticChecks is explicitly false, auto-updates are
disabled.
- When 'auto-update' is set, use its value to set Sparkle's auto-update
behavior.
This fixes https://github.com/ghostty-org/ghostty/issues/3535 .
There exists an issue in ghostty on mac where if you have hidden your
titlebar, then enter fullscreen, the titlebar will reappear after
exiting fullscreen.
The reason for this is that after exiting fullscreen macos reapplies
some styling on the new window created after exiting fullscreen. To
combat this we will reapply the styling to hide the titlebar after
exiting fullscreen.
Required config:
```
macos-titlebar-style = hidden
macos-non-native-fullscreen = true
```
Steps to reproduce:
- Open Ghostty
- Enter fullscreen (non-native)
- Exit fullscreen
On main you will see the titlebar reappearing after exiting fullscreen,
while that does not happen with this patch.
Renames the top/bottom directions of `goto_split` to up/down. I have
tested this on linux (nixos) but given that `goto_split` is broken on
linux anyway (#2866) there's not a whole lot to test.
I have no way to build on macOS so I can't verify that I've changed
everything correctly for that.
Closes#3237
~~When processing toggle_fullscreen actions, multiple FullscreenStyle
derived objects would register observers on the same window and
subsequently remove them when the old style was deinited.~~
~~This change passes ownership of the fullscreenNotification observers
to TerminalController while still allowing FullscreenStyles access to
the window for style specific actions.~~
We need to have at least one fullscreen style (even if it is not being
used) to make sure that observers for fullscreen state changes are set
up. An alternative approach would be the first version of this PR (for
which my reasoning was wrong but the end change was correct) which
registers the fullscreen observers at either the TerminalController or
BaseTerminalController level.
Fixes#3553
The auto-update prompt isn't useful for local (source) builds. Disable
it by default by setting Sparkle's SUEnableAutomaticChecks Info.plist
key to NO (false) for all build configurations.
We then selectively re-enable it by deleting that Info.plist key from
our release workflows. We delete the key instead of setting its value to
YES (true) to give us Sparkle's default behavior of prompting the user
to enable update checks on the second application launch. (YES tells
Sparkle to skip that prompt and silently enable update checks.)
See also: https://sparkle-project.org/documentation/customization/
The auto-update prompt isn't useful for local (source) builds so disable
both update checks and automatic downloads for the Debug and Release
configurations.
Fixes#3179
This approach uses Xcode's Info.plist preprocessing to conditionally set
`SUEnableAutomaticChecks=false` for the Debug and Release build schemes.
It is unset for the ReleaseLocal scheme.
When this Info.plist key is explicitly set to false (as it is for these
build schemes), we disable auto-updates at runtime. Otherwise, we apply
the behavior defined by our "auto-update" configuration.
The auto-update prompt isn't useful for local (source) builds so disable
both update checks and automatic downloads.
There are multiple ways we could check if we've been built for source,
but the easiest and least intrusive approach is to check the value of
the 'GhosttyCommit' Info.plist key. Because it is only set as part of
the release build process, an empty key implies that we've been build
from source.
Fixes#3117
On mouseExit we sent a cursor position event with (-1, -1). Negative
values are meant to indicate that the cursor is not on the surface. The
magnitude of the values are irrelevant. However, we never reset the
cursor position on mouseEnter.
This has the effect of the previous cursor position being stuck outside
the viewport which makes certain things such as `button` mouse reporting
not report until the mouse is moved.
This commit sends the correct cursor position event on mouseEnter.
Related to #2731
I'm not fully sure if this will fix this issue since I can't reproduce
it but I don't see a downside to doing this and it might fix it.
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.
