As recommended in
https://github.com/ghostty-org/ghostty/pull/4927#issuecomment-2585003934,
adds a config option `maximize` for starting a window in a maximized
state in terms of window properties. Also adds a `toggle_maximize`
keybind to allow users to manually toggle this feature on and off.
It might make more sense to make this an optional config value so that
we don't toggle the state off if the WM already handles that for us, but
I'll let a reviewer decide.
Closes https://github.com/ghostty-org/ghostty/issues/4646
This changes quit signaling from a boolean return from core app `tick()`
to an apprt action. This simplifies the API and conceptually makes more
sense to me now.
This wasn't done just for that; this change was also needed so that
macOS can quit cleanly while fixing #4540 since we may no longer trigger
menu items. I wanted to split this out into a separate commit/PR because
it adds complexity making the diff harder to read.
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.
Rather than storing a list of errors we now store a list of
"diagnostics." Each diagnostic has a richer set of structured
information, including a message, a key, the location where it occurred.
This lets us show more detailed messages, more human friendly messages, and
also let's us filter by key or location. We don't take advantage of
all of this capability in this initial commit, but we do use every field
for something.
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.
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#1547
The core change to make this work is to make the cursor position
callback support taking updated modifiers. On both macOS and GTK, cursor
position events also provide the pressed modifiers so we can pass those
in.
Mitchell Hashimoto