The comptime path of the GTK `atLeast()` version function fails to take
the proceeding 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).
This update required that the major versions be equal when comparing
minor versions and the major and minor versions be equal when comparing
micro versions.
For example, building against GTK 4.17.1:
Before: version.atLeast(4,16,2) -> false
After: version.atLeast(4,16,2) -> true
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
As a follow-up to #3477 and #3748, this eliminates the use of dlopen to
access `libX11` functions by directly linking `libX11` if X11 is
enabled. This should also fix problems with systems like NixOS and Void
Linux that have reported problems using Ghostty on X11 when using the
distribution packages.
This gives people finer-grained control over the coloring of their
window titlebars. Currently only implemented for GTK.
Signed-off-by: Tristan Partin <tristan@partin.io>
This looks better than the regular dark color. It also happens to match
what Ptyxis does. It does not support non-libadwaita builds.
Signed-off-by: Tristan Partin <tristan@partin.io>
According to the GNOME human interface guidelines, buttons for the main
user actions, such as new, add, open, and back should be placed at the
start of the header bar. (https://developer.gnome.org/hig/patterns/containers/header-bars.html#header-bar-buttons)
Moving the new tab button to the start of the header bar brings Ghostty
in line with other GNOME applications such as gedit and gnome-terminal.
Fixes#2092
This isn't perfect because it only prevents _new_ splits from being
too small. You can still resize the window to make them smaller. This
just helps prevent the very-easy-to-trigger crash of #2092.
We don't need to do this to macOS because it doesn't crash in the same
way with zero-sized splits.
Long term we should really chase down what breaks in GTK at a root level
when we have zero-sized splits. But this is a quick fix for now to
prevent the easy crash I feel like people might stress test and run into
with the 1.0 release.
This backs out commit bb185cf6b695420ce8b43b5c1cadd16ef71c481a.
This was breaking IME input for some users and overall I couldn't find
other users where this really fixed anything other than me so I'm going
to back this out and fix this using my own system.
The surface might be mutated during the clipboard confirmation (resized
in my case), leading to the copied cursor `page_pin` being invalidated.
Fixes#1714. Would be nice if @stgarf can verify this.
I agree to the MIT relicensing.
A common issue for US-centric users of a terminal is that the "option"
key on macOS is not treated as the "alt" key in the terminal.
## Background
macOS does not have an "alt" key, but instead has an "option" key. The "option"
key is used for a variety of purposes, but the troublesome behavior for some
(and expected/desired behavior for others) is that it is used to input special
characters.
For example, on a US standard layout, `option-b` inputs `∫`. This is not
a typically desired character when using a terminal and most users will
instead expect that `option-b` maps to `alt-b` for keybinding purposes
with whatever shell, TUI, editor, etc. they're using.
On non-US layouts, the "option" key is a critical modifier key for
inputting certain characters in the same way "shift" is a critical
modifier key for inputting certain characters on US layouts.
We previously tried to change the default for `macos-option-as-alt`
to `left` (so that the left option key behaves as alt) because I had the
wrong assumption that international users always used the right option
key with terminals or were used to this. But very quickly beta users
with different layouts (such as German, I believe) noted that this is
not the case and broke their idiomatic input behavior. This behavior was
therefore reverted.
## Solution
This confusing behavior happened frequently enough that I decided to
implement the more complex behavior in this commit. The new behavior is
that when a US layout is active, `macos-option-as-alt` defaults to true
if it is unset. When a non-US layout is active, `macos-option-as-alt`
defaults to false if it is unset. This happens live as users change
their keyboard layout.
**An important goal of Ghostty is to have zero-config defaults** that
satisfy the majority of users. Fiddling with configurations is -- for
most -- an annoying task and software that works well enough out of the
box is delightful. Based on surveying beta users, I believe this commit
will result in less configuration for the majority of users.
## Other Terminals
This behavior is unique amongst terminals as far as I know.
Terminal.app, Kitty, iTerm2, Alacritty (I stopped checking there) all
default to the default macOS behavior (option is option and special
characters are inputted).
All of the aforementioned terminals have a setting to change this
behavior, identical to Ghostty (or, Ghostty identical to them perhaps
since they all predate Ghostty).
I couldn't find any history where users requested the behavior of
defaulting this to something else for US based keyboards. That's
interesting since this has come up so frequently during the Ghostty
beta!
❤️👻
This is the icon that we'll launch Ghostty 1.0 with. It was designed by
Michael Flareup at PixelResort. It retains the style of the original
Ghostty icon by Alasdair Monk, but brings in the new Ghost character and
adds details that make it more Apple-like.
The new Ghost character is an important evolution from the original
since it separates us from looking too much like PacMan. The new Ghost
is more unique and recognizable to Ghostty (or, hopefully will be!).
The icon itself has more details: the aluminum around the edge has
texture for the large enough sizes, there are visible scanlines, the
glow of a screen emanates from the ghost.
The icon itself is stylistic more Apple-like than other platforms. I
think Apple icons tend to look very good in more environments than the
reverse and I'm a big fan of the Apple aesthetic so I wanted to bring
that to Ghostty for all platforms.
