follow-up to #4520
all the same stuff for the previous two
the tests for this only run for the native target and was added for the
iOS build (3360a008cd137b428631fc8052f64d672a660240), I've made a second
version of this commit to remove the native check if thats more desired
(d247a22de036140297942701090e0eafb3d1a72d)
ghostty and all tests appear to run on my system both with and without
system integration
In #4388, documentation was added for goto_split but in #3427 this
documentation was made outdated but not updated. This makes the
documentation up to date and brings the ordering in line with new_split
This is achieved by rendering to an alpha-only context rather than a
normal single-channel context, and adjusting the brightness at which
coretext thinks it's drawing the glyph, which affects how it applies
font smoothing (which is what `font-thicken` enables).
Fixes#4518
If our UTF8 encoding is not recognized, we fall back to the ASCII
mapping of the logical key for the control sequence. This allows
cyrillic control characters to work.
I also verified that non-cyrllic (US) and alternate layouts (Dvorak)
work as expected still.
same as #4205 but for fontconfig
it follows the same pattern with one addition:
the module needs a known target to be able to link a system library
I don't think this will affect anything
ghostty and all tests appear to run on my system both with and without
system integration
Fixes#4518
If our UTF8 encoding is not recognized, we fall back to the ASCII
mapping of the logical key for the control sequence. This allows
cyrillic control characters to work.
I also verified that non-cyrllic (US) and alternate layouts (Dvorak)
work as expected still.
The cimgui version listed does not match the upstream commit or the
vendored cimgui files
Checking the upstream `git log` the commit corresponds to `commit
e391fe2e66eb1c96b1624ae8444dc64c23146ef4 (tag: v1.90.6-docking)` however
the `build.zig.zon` is outdated.
The vendored cimgui files also contain the header
```cpp
// This file is automatically generated by generator.lua from
// https://github.com/cimgui/cimgui based on imgui.h file version "1.90.6" 19060
// from Dear ImGui https://github.com/ocornut/imgui with imgui_internal.h api
// docking branch
```
I wasn't too clear with what the comment meant:
```
// This should be kept in sync with the submodule in the cimgui source
// code to be safe that they're compatible.
```
and assumed it was referring to the vendored cimgui files, added a
comment pointing out where to find the cimgui source mentioned.
When searching in the theme list (e.g., searching for "Snazzy"), some matching themes might be hidden due to incorrect window position handling.
This fix ensures all matching themes are visible by adjusting the window position logic.
Current sort used by `+list-keybinds` doesn't include the value of the
key:
```
ctrl + shift + v paste_from_clipboard
ctrl + shift + a select_all
...
ctrl + shift + q quit
ctrl + shift + n new_window
...
alt + five goto_tab:5
alt + eight goto_tab:8
...
alt + six goto_tab:6
alt + seven goto_tab:7
```
adding the key value improves the sort order
```
ctrl + shift + a select_all
ctrl + shift + c copy_to_clipboard
...
ctrl + shift + n new_window
ctrl + shift + o new_split:right
ctrl + shift + q quit
...
alt + one goto_tab:1
alt + two goto_tab:2
alt + three goto_tab:3
...
alt + eight goto_tab:8
alt + nine last_tab
alt + f4 close_window
closes#4328closes#3970
makes this possible now
```
keybind = performable:ctrl+c=copy_to_clipboard # copy if theres a selection else send sigint
keybind = ctrl+v=paste_from_clipboard
```
After updating to 1.0.1 I noticed something different in the terminal,
which turned out being the window borders - it appeared as if Ghostty
was using light-mode style borders (dark/black outline with a thin light
stroke at the top) instead of the entire light outline from before:
| 1.0.0 | 1.0.1 |
| - | - |
| <img width="308" alt="Screenshot 2025-01-01 at 2 28 12 PM"
src="https://github.com/user-attachments/assets/d8bc5bdd-c3b2-401c-a8ed-9da0b768cb3d"
/> | <img width="308" alt="Screenshot 2025-01-01 at 2 29 07 PM"
src="https://github.com/user-attachments/assets/fd710bed-1756-4f66-8402-bfbdd25218ab"
/> |
After digging a bit, I found #3834, which fixes fullscreen background
colors through alpha channels by appending a `withAlphaComponent(0.0)`
to `backgroundColor` - for reasons I may be entirely unaware of (since
I'm not a Swift developer), this seems to cause the dark-mode border
style to go away.
Some lines above that, I noticed the `.clear` callout from line 266,
which talks about matching Terminal.app's styles, and it _also_ has a
`withAlphaComponent` but set to `0.001` - if I understand correctly, and
the fix from #3834 works by setting the alpha component to a
_practically_ zero value, then I thought perhaps a really small number
like `0.001` could do the trick as well. This ended up working and
bringing back the right borders again.
Not sure again if this may make a difference anywhere else in the app or
bring any undesired behavior, but if anyone who is well-versed in Swift
would like chime in with more details or perhaps a better approach, I'd
greatly appreciate it!
