Fixes#4218
This now requires a separate manually triggered `publish` workflow to be
run after the release completes in order to transition the release to
the `published` state.
Practically today this only means that the release will be published to
the macOS auto-updater, but in the future we could add additional steps
such as creating a GH release or some other notifications.
Importantly, this lets us verify the release in the uploaded location
before general users are notified of the update.
This now requires a separate manually triggered `publish` workflow to be
run after the release completes in order to transition the release to
the `published` state.
Practically today this only means that the release will be published to
the macOS auto-updater, but in the future we could add additional steps
such as creating a GH release or some other notifications.
Importantly, this lets us verify the release in the uploaded location
before general users are notified of the update.
Fixes#4522
This is a bit of a hammer-meets-nail solution, but it's a simple
solution to the problem. The reverse mapping is used to find the binding
that an action is bound to, and it's used by apprt's to populate the
accelerator label in the UI.
The problem is that accelerators in GTK are handled early in the event
handling process and its difficult to get that event mapping to a
specific surface. Therefore, the "performable" prefix was not working.
On macOS, this issue didn't exist because there exists an OS mechanism
to install an event handler earlier than the menu system.
This commit changes the reverse mapping to only include bindings that
are not performable. This way, the keybind always reaches the surface
and can be handled by `Surface.keyCallback` which processes
`performable`.
The caveat is that performable bindings will not show up in the UI for
menu items. This is documented in this commit now. They still work, its
just a UI issue.
Resolves#4730
I opted to link directly to the release notes of the updated version in
the `<description>` body, i.e. in the future it would link directly
v1.0.2's release notes at
https://ghostty.org/docs/install/release-notes/1-0-2. This thereby
implements the second option mentioned in the issue. It wasn't that much
harder than the third option, but if there's any particular reason _not
to_ link directly to a version's changelog page, I'll be more than happy
to modify this PR and implement the third option instead - in any case,
I had opened https://github.com/ghostty-org/website/pull/277 so that
https://ghostty.org/docs/install/release-notes is a valid page.
I also wrapped the current text `<![CDATA[ ... ]]>` just in case, as I
noticed this is a pretty standard practice in other apps that use
`<description>` to embed their release notes when using Sparkle -
[Sparkle's
documentation](https://sparkle-project.org/documentation/publishing/#embedded-release-notes)
says to do this so you can use unescaped HTML.
Fixes#4522
This is a bit of a hammer-meets-nail solution, but it's a simple
solution to the problem. The reverse mapping is used to find the
binding that an action is bound to, and it's used by apprt's to populate
the accelerator label in the UI.
The problem is that accelerators in GTK are handled early in the event
handling process and its difficult to get that event mapping to a
specific surface. Therefore, the "performable" prefix was not working.
On macOS, this issue didn't exist because there exists an OS mechanism
to install an event handler earlier than the menu system.
This commit changes the reverse mapping to only include bindings that
are not performable. This way, the keybind always reaches the surface
and can be handled by `Surface.keyCallback` which processes
`performable`.
The caveat is that performable bindings will not show up in the UI
for menu items. This is documented in this commit now. They still work,
its just a UI issue.
I found this bug was easily reproduced with any command that wrapped to
multiple rows on the first line of its output. The cause is that we stop
searching for rows once we reach the first one where
`row.semantic_prompt = .command`, which means that we reach the bottom
line of wrapped output and stop there.
This PR makes it so that we continue iterating until we reach a row
where `semantic_prompt != .command` and then return the previous one (or
the last one if we run out of rows).
I also updated the test cases to include this.
I considered that this bug would also be avoided if we didn't propagate
the `command` semantic prompt to additional rows on wrapped lines, but I
don't know enough about the shell integration to make a call on that.
Closes#4693
When setting up the GTK window with older Adwaita versions, we need to
explicitly create and add a tab bar. The previous code simply prepended
the tab bar into the GtkBox, which resulted in it being the very first
element (ahead of the title bar).
Instead, we grab a reference to the GTK title bar widget and call
`gtk_box_insert_child_after()` to explicitly insert our tab bar into the
hierarchy just after the title bar.
More mathematically sound approach, does a much better job of matching
the appearance of non-linear blending. Removed `experimental` from name
because it's not really an experiment anymore.
Related to #5361
The fix in 5361 wasn't sufficient since it only applied if our app was
in the foreground. Our quick terminal is a non-activating NSPanel to
allow it to work on any space (fullscreen included). This means that
Ghostty doesn't become the active app when the quick terminal is shown
and another app is in the foreground.
To work around this, we now hide the dock globally when the quick
terminal is shown AND the dock is in a conflicting position. We restore
this state when the quick terminal is hidden, loses focus, or Ghostty is
quit.
Related to #5361
The fix in 5361 wasn't sufficient since it only applied if our app was
in the foreground. Our quick terminal is a non-activating NSPanel to
allow it to work on any space (fullscreen included). This means that
Ghostty doesn't become the active app when the quick terminal is shown
and another app is in the foreground.
To work around this, we now hide the dock globally when the quick
terminal is shown AND the dock is in a conflicting position. We restore
this state when the quick terminal is hidden, loses focus, or Ghostty is
quit.
Related to #4446 , as suggested i've made a smaller chunk of updates for
the action binding docs, including arguments and examples. I did this
only for enum types this time.
I've also included the argument type name in the Argument (e.g.
AdjustSelection).
Not sure if we should include the keybindings or not in the example?
I also added a format of some unrelated code change.
Print chorded/sequenced keybinds in `+list-keybinds`.
Recursively traverses the binding sets of sequenced keybinds and builds
a singly-linked list of triggers for each leaf. Also adapted the current
sorting criteria to work for multiple triggers per keybind.
Chorded keybinds are already output when not printing to a tty so that
code path is unchanged.
Closes#4505
Fixes#5328
The dock sits above the level of the quick terminal, and the quick
terminal frame typical includes the dock. Hence, if the dock is visible
and the quick terminal would conflict with it, then part of the terminal
is obscured.
This commit makes the dock autohide if the quick terminal would conflict
with it. The autohide is disabled when the quick terminal is closed.
We can't set our window level above the dock, as this would prevent
things such as input methods from rendering properly in the quick
terminal window.
iTerm2 (the only other macOS terminal I know of that supports a dropdown
mode) frames the terminal around the dock. I think this looks less
aesthetically pleasing and I prefer autohiding the dock instead.
We can introduce a setting to change this behavior if desired later.
Additionally, this commit introduces a mechanism to safely set
app-global presentation options from multiple sources without stepping
on each other.
## Demo
https://github.com/user-attachments/assets/1f5bb945-dca4-49e7-8bcb-95b55524cfb5
Fixes#5328
The dock sits above the level of the quick terminal, and the quick
terminal frame typical includes the dock. Hence, if the dock is visible
and the quick terminal would conflict with it, then part of the terminal
is obscured.
This commit makes the dock autohide if the quick terminal would conflict
with it. The autohide is disabled when the quick terminal is closed.
We can't set our window level above the dock, as this would prevent
things such as input methods from rendering properly in the quick
terminal window.
iTerm2 (the only other macOS terminal I know of that supports a dropdown
mode) frames the terminal around the dock. I think this looks less
aesthetically pleasing and I prefer autohiding the dock instead.
We can introduce a setting to change this behavior if desired later.
Additionally, this commit introduces a mechanism to safely set
app-global presentation options from multiple sources without stepping
on each other.
Fixes#5359
The comments explain what's going on. Longer term we should adjust our
termio/exec to avoid the SIGPIPE but its still possible (i.e. that
thread crashes) to happen so we should be robust to it.
Fixes#5359
The comments explain what's going on. Longer term we should adjust our
termio/exec to avoid the SIGPIPE but its still possible (i.e. that
thread crashes) to happen so we should be robust to it.
Fixes#5253
Add -Demit-terminfo and -Demit-termcap build options to enable/disable
installation of source terminfo and termcap files.
Replacement for #5311
Fixes#4554
When a process exited on its own (we didn't kill it), we were not
calling waitpid. This commit adds a waitpid call in the event loop
process exit notification.
This happened because when an external exit happened we could call
`subprocess.externalExit` which tells our subprocess manager to NOT kill
the process (since its already dead). Unfortunately in this case it
means we also didn't call waitpid.
Fixes#4554
xev.Process.wait is documented as being equivalent to calling `waitpid`,
i.e. including reaping the process. On Linux, it does this automatically
by using pidfd and the `waitid` syscall. On macOS, it wasn't doing this.
This commit updates libxev to include a fix that explicitly calls
`waitpid` for kqueue.
Fixes#4884
When our command exits, it will close the pty slave fd. This will
trigger a HUP on our poll. Previously, we only checked for IN. When a fd
is closed, IN triggers forever which would leave to an infinite loop and
100% CPU.
Now, detect the HUP and exit the read thread.
Fixes#4884
When our command exits, it will close the pty slave fd. This will
trigger a HUP on our poll. Previously, we only checked for IN. When a fd
is closed, IN triggers forever which would leave to an infinite loop and
100% CPU.
Now, detect the HUP and exit the read thread.
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.
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.
Mitchell Hashimoto