Before this change, there seemed to be some artifacting in the window
corners due to the window border no longer outlining the content
properly. By detecting the situation, we can turn the window border
radius off.
Before this change, there seemed to be some artifacting in the window
corners due to the window border no longer outlining the content
properly. By detecting the situation, we can turn the window border
radius off.
Signed-off-by: Tristan Partin <tristan@partin.io>
If a blur radius config value was previously set but then removed or set
to 0, the new blur radius would not take effect on config reload due to
the early return clause.
The comptime path of the GTK `atLeast()` version function fails to take
the preceeding portion of the version into account. For example version
5.1.0 is incorrectly marked as less than 4.16.7 due to the minor version
(1) being less than the minor we are comparing against (16).
For example, building against GTK 4.17.1:
Before: version.atLeast(4,16,2) -> false
After: version.atLeast(4,16,2) -> true
Fixes#3202
Two changes to get here:
1. Do not fail startup if crash reporting initialization fails. This is
a non-critical feature and should not prevent the terminal from
starting.
2. Avoid freeing Sentry transport on error path. This segfaults.
Upstream issue will be reported separately.
Fixes#3202
Two changes to get here:
1. Do not fail startup if crash reporting initialization fails. This is a
non-critical feature and should not prevent the terminal from starting.
2. Avoid freeing Sentry transport on error path. This segfaults.
Upstream issue will be reported separately.
The auto-update prompt isn't useful for local (source) builds. Disable
it by default by setting Sparkle's SUEnableAutomaticChecks Info.plist
key to NO (false) for all build configurations.
We then selectively re-enable it by deleting that Info.plist key from
our release workflows. We delete the key instead of setting its value to
YES (true) to give us Sparkle's default behavior of prompting the user
to enable update checks on the second application launch. (YES tells
Sparkle to skip that prompt and silently enable update checks.)
See also: https://sparkle-project.org/documentation/customization/
(This is a safer alternative to #3273.)
Fixes: #3179
Continuing from #3043 I agree that it seems idiomatic to have an archive
with format <name>-<version>.tar.gz and matching prefix for packaging,
RPM and Debian packaging guides seem to assume this format and the
automated extract tooling assumes it too.
# Testing
I haven't tested running this workflow, and am unsure about the yaml
substitution at lines 105-106
# Breaking changes
This would break existing packaging scripts, not sure how we want to
version it
The auto-update prompt isn't useful for local (source) builds. Disable
it by default by setting Sparkle's SUEnableAutomaticChecks Info.plist
key to NO (false) for all build configurations.
We then selectively re-enable it by deleting that Info.plist key from
our release workflows. We delete the key instead of setting its value to
YES (true) to give us Sparkle's default behavior of prompting the user
to enable update checks on the second application launch. (YES tells
Sparkle to skip that prompt and silently enable update checks.)
See also: https://sparkle-project.org/documentation/customization/
The auto-update prompt isn't useful for local (source) builds so disable
both update checks and automatic downloads for the Debug and Release
configurations.
Fixes#3179
The renderer must track if the foreground, background, and cursor colors
are explicitly set by an OSC so that changes are not overridden when the
config file is reloaded.
Fixes: https://github.com/ghostty-org/ghostty/issues/2795
https://github.com/ghostty-org/ghostty/pull/3130 do over. Github seems
to have lost track of the fork status for the previous work. (perhaps
permissions?). Rebased the PR to main as I can't see why it could
possibly fail.
<details>
<summary>Previous description</summary>
Bit of a rabbit hole came up while trying to package ghostty for nixos.
zig build test would just hang when run as part of checkPhase in a nix
build. (rather than the nix develop ... command run in CI).
Here's what I understand so far:
/usr/bin/env does not exist in a nix build sandbox. This only works as a
test binary when running in nix develop as it shares its environment
with the user where this compatibility crutch exists.
When executing Command.zig tests that reference /usr/bin/env the
eventual call to fork+execevZ will duplicate the running test process as
execevZ returns rather than dissapearing into the new exec'd process.
Duplicating a test process via fork does unexepected things. zig build
test will hang for <reasons?>. A test binary created via -Demit-test-exe
will run two copies of the test suite producing two different failure
outputs for the same test. (or ~4 copies of the test framework, one
extra for each test that fails this way)
/bin/sh can be used and an alternative test target. It isn't amazing as
it's relying on stdenv creating /bin/sh and it just existing on user
systems. Other alternatives I can think of would require build flags or
some sort of contract with packaging around what binary will exist for
the Command.zig tests.
</details>
We refresh the link hover state in two (generic) cases
1. When the modifiers change
2. When the cursor changes position
Each of these have additional state qualifiers. Modify the qualifiers
such that we refresh links under the following scenarios:
1. Modifiers change
- Control is pressed (this is handled in the renderer)
- Mouse reporting is off
OR
Mouse reporting is on AND shift is pressed AND we are NOT reporting
shift to the terminal
2. Cursor changes position
- Control is pressed (this is handled in the renderer)
- We previously were over a link
- The position changed (or we had no previous position)
- Mouse reporting is off
OR
Mouse reporting is on AND shift is pressed AND we are NOT reporting
shift to the terminal
This fixes a few issues with the previous implementation:
1. If mouse reporting was on and you were over a link, pressing ctrl
would enable link hover state. If you moved your mouse, you would
exit that state. The logic in the keyCallback and the
cursorPosCallback was not the same. Now, they both check for the same
set of conditions
2. If mouse reporting was off, you could hold control and move the mouse
to discover links. If mouse reporting was on, holding control + shift
would not allow you to discover links. You had to be hovering one
when you pressed the modifiers. Previously, we only refreshed links
if we *weren't* reporting the mouse event. Now, we refresh links even
even if we report a mouse event (ie a mouse motion event with the
shift modifier pressed *will* hover links and also report events)
