Fixes#6999
Supersedes #7201
It appears that at some point one of the operations causes focus to move
away for non-native fullscreen. We previously relied on the delegate
method to restore this but a better approach appears to handle this
directly in the fullscreen implementations. This fixes the linked issue.
I still think long term all the `Ghostty.moveFocus` stuff is a code
smell and we should be auditing all that code to see if we can eliminate
it. But this is a step in the right direction, and removes one of those
uses.
Fixes#6999
It appears that at some point one of the operations causes focus to move
away for non-native fullscreen. We previously relied on the delegate
method to restore this but a better approach appears to handle this
directly in the fullscreen implementations. This fixes the linked issue.
I still think long term all the `Ghostty.moveFocus` stuff is a code
smell and we should be auditing all that code to see if we can
eliminate it. But this is a step in the right direction, and removes one
of those uses.
Fixes#7114
Supercedes #7271
This fixes a crash that could occur with non-native fullscreen and
`fullscreen = true` set at once.
The "windowNumber" can be `<= 0` if the window "doesn't have a window
device." I don't fully know all the scenarios this is true but it is
true when the window is not visible, at least.
Fixes#7114
Supercedes #7271
This fixes a crash that could occur with non-native fullscreen and
`fullscreen = true` set at once.
The "windowNumber" can be `<= 0` if the window "doesn't have a
window device." I don't fully know all the scenarios this is true but it
is true when the window is not visible, at least.
tl;dr: FT_New_Face and FT_Done_Face require the Library to be locked for
thread safety, and FT_Load_Glyph and FT_Render_Glyph and friends need
the face to be locked for thread safety, since we're sharing faces
across threads.
For details see comments and FreeType docs @
-
https://freetype.org/freetype2/docs/reference/ft2-library_setup.html#ft_library
-
https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face
---
This might resolve the issue discussed in #7016 but I wasn't able to
reliably reproduce it in a way I could debug, so someone who was
experiencing it should probably test this PR.
Additionally I can still semi-reliably produce a crash with the GTK
apprt by setting an `all:` keybind to adjust font sizes and changing the
font size rapidly with many surfaces open with emojis on them.
Unfortunately I can't really tell what the root cause is because the
debug info is broken in QEMU.
However, I do think this is a good idea for us to be thread safe with
this stuff even if it isn't related to that problem.
Prior to #7044, on macOS, our shell integrated command line would be
executed under `exec -l`, which caused bash to be started as a login
shell. Now that we're using direct command execution, add `--login` to
our bash command's arguments on macOS to get that same behavior.
After some time with the initial template and Discussions being created,
there are some improvements we should make to the Issue Triage template.
Most of these changes were discussed in #7012 and among helpers in the
Discord.
~~I've marked this as a Draft for now as I work with the helpers to
confirm how we want to approach a few of the outstanding changes, mostly
minor updates.~~
As always, you can test these out by [opening an Issue Triage Discussion
post on my
fork](https://github.com/taylrfnt/ghostty/discussions/new?category=issue-triage).
Prior to #7044, on macOS, our shell integrated command line would be
executed under `exec -l`, which caused bash to be started as a login
shell. Now that we're using direct command execution, add `--login` to
our bash command's arguments on macOS to get that same behavior.
