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#2857
Some terminal modes always reset, but there are others that should be
conditional based on how the terminal's default state is configured.
Primarily from #2857 is the grapheme clustering mode (mode 2027) which
was always resetting to false but should be conditional based on the
the `grapheme-width-method` configuration.
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.
Removed check for plasma in build.zig, it installs it anyways now
Added executable permissions for ghostty_dolphin.desktop since Plasma
requires them for context menu items
Fixes#2781
This commit contains two separate changes but very related:
1. We update the color scheme state of the app on app start. This is
necessary so that the configuration properly reflects the conditional
state of the theme at the app level (i.e. the window headerbar).
2. We take ownership of the new config when it changes, matching macOS.
This ensures that things like our GTK headerbar update when the theme
changes but more generally whenever any config changes.
And some housekeeping:
- We remove runtime CSS setup from init. We can do it on the first tick
of `run` instead. This will probably save some CPU cycles especially
when we're just notifying a single instance to create a new window.
- I moved dbus event setup to `run` as well. We don't need to know these
events unless we're actually running the app. Similar to the above,
should save some CPU time on single instance runs.
This sets the macOS QoS class of the renderer thread. Apple
recommends[1] that all threads should have a QoS class set, and there
are many benefits[2] to that, mainly around power management moreso than
performance I'd expect.
In this commit, I start by setting the QoS class of the renderer thread.
By default, the renderer thread is set to user interactive, because it
is a UI thread after all. But under some conditions we downgrade:
- If the surface is not visible at all (i.e. another window is fully
covering it or its minimized), we set the QoS class to utility. This
is lower than the default, previous QoS and should help macOS
unschedule the workload or move it to a different core.
- If the surface is visible but not focused, we set the QoS class to
user initiated. This is lower than user interactive but higher than
default. The renderer should remain responsive but not consume as
much time as it would if it was user interactive.
I'm unable to see any noticable difference in anything from these
changes. Unfortunately it doesn't seem like Apple provides good tools to
play around with this.
We should continue to apply QoS classes to our other threads on macOS.
[1]: https://developer.apple.com/documentation/apple-silicon/tuning-your-code-s-performance-for-apple-silicon?preferredLanguage=occl
[2]: https://blog.xoria.org/macos-tips-threading/
Fixes#2817
The test is pretty explanatory. I also renamed `end` to `count` since I
think this poor naming was the reason for the bug. In `eraseChars`, the
`count` (nee `end`) is the number of cells to erase, not the index of
the last cell to erase.
This resolves the toast showing up every time the surface config changes
which can be relatively frequent under certain circumstances such as
theme changes.
