`WINDOWID` is the conventional environment variable for scripts that
want to know the X11 window ID of the terminal, so that it may call
tools like `xprop` or `xdotool`. We already know the window ID for
window protocol handling, so we might as well throw this in for
convenience.
Multiple fixes to prevent file descriptor leaks:
- libxev eventfd now uses CLOEXEC
- linux: cgroup clone now uses CLOEXEC for the cgroup fd
- termio pipe uses pipe2 with CLOEXEC
- pty master always sets CLOEXEC because the child doesn't need it
- termio exec now closes pty slave fd after fork
There still appear to be some fd leaks happening. They seem related to
GTK, they aren't things we're accessig directly. I still want to
investigate them but this at least cleans up the major sources of fd
leakage.
The variant format string `^aay` is said to be equivalent to
`g_variant_new_bytestring_array`. Given that no length parameter is
provided, glib assumed a null-terminated array, causing a crash as glib
exceed the read boundaries to copy arbitrary memory.
This commit replaces the array construction code to use its arena
equivalents instead of glib, and make sure that the resulting array is
null-terminated.
Fixes#3616.
The variant format string `^aay` is said to be equivalent to
g_variant_new_bytestring_array. Given that no length parameter is
provided, g_variant_new assumed a null-terminated array, but the array
constructed by the code was not, causing a crash as glib exceed the read
boundaries to copy arbitrary memory.
This commit replaces the array construction code to use its arena
equivalents instead of trying to build one using glib, and make sure
that the resulting array is null-terminated.
Fixes#3953Fixes#3284
This fixes two issues. In fixing one issue, the other became apparent so
I fixed both in this one commit.
The first issue is that on macOS, the `open` command should take the
`-t` flag to open text files in a text editor. To do this, the `os.open`
function now takes a type hint that is used to better do the right
thing.
Second, the order of the paths that we attempt to open when editing a
config on macOS is wrong. Our priority when loading configs is well documented:
https://ghostty.org/docs/config#macos-specific-path-(macos-only). But
open_config does the opposite. This makes it too easy for people to have
configs that are being overridden without them realizing it.
This commit changes the order of the paths to match the documented
order. If neither path exists, we prefer AppSupport.
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/
I hit an edge case when using Private Wi-Fi addressing on macOS where
the last section of the randomized mac address starts with a '0'. The
hostname parsing for the shell integration didn't handle this case, so
issue #2512 reappeared.
This fixes that by explicitly handling port numbers < 10.
Note that this includes some failing tests because I want to make the
uri handling better and more specific. It's a little bit too general
right now so I want to lock it down to:
1. macOS only; and
2. valid mac address values
because that's how the macOS private Wi-Fi address thing works;
randomizes your mac address and sets that as your hostname.
