| Age | Commit message (Collapse) | Author |
|---|
|
This reduces the surface area of files we depend on for builds.
|
|
|
|
We don't really have any large outstanding regressions on -ng to warrant
keeping this alive anymore. ¡Adiós!
|
|
|
|
|
|
|
|
|
|
|
|
Instead of using @hasDecl, use a performAction-stype API. The C
interface for interfacing with macOS (or any other apprt where Ghostty
is embedded) is unfinished.
|
|
|
|
This deletes the GLFW apprt from the Ghostty codebase.
The GLFW apprt was the original apprt used by Ghostty (well, before
Ghostty even had the concept of an "apprt" -- it was all just a single
application then). It let me iterate on the core terminal features,
rendering, etc. without bothering about the UI. It was a good way to get
started. But it has long since outlived its usefulness.
We've had a stable GTK apprt for Linux (and Windows via WSL) and a
native macOS app via libghostty for awhile now. The GLFW apprt only
remained within the tree for a few reasons:
1. Primarily, it provided a faster feedback loop on macOS because
building the macOS app historically required us to hop out of the
zig build system and into Xcode, which is slow and cumbersome.
2. It was a convenient way to narrow whether a bug was in the
core Ghostty codebase or in the apprt itself. If a bug was in both
the glfw and macOS app then it was likely in the core.
3. It provided us a way on macOS to test OpenGL.
All of these reasons are no longer valid. Respectively:
1. Our Zig build scripts now execute the `xcodebuild` CLI directly and
can open the resulting app, stream logs, etc. This is the same
experience we have on Linux. (Xcode has always been a dependency of
building on macOS in general, so this is not cumbersome.)
2. We have a healthy group of maintainers, many of which have access
to both macOS and Linux, so we can quickly narrow down bugs
regardless of the apprt.
3. Our OpenGL renderer hasn't been compatible with macOS for some time
now, so this is no longer a useful feature.
At this point, the GLFW apprt is just a burden. It adds complexity
across the board, and some people try to run Ghostty with it in the real
world and get confused when it doesn't work (it's always been lacking in
features and buggy compared to the other apprts).
So, it's time to say goodbye. Its bittersweet because it is a big part
of Ghostty's history, but we've grown up now and it's time to move on.
Thank you, goodbye.
(NOTE: If you are a user of the GLFW apprt, then please fork the project
prior to this commit or start a new project based on it. We've warned
against using it for a very, very long time now.)
|
|
First, this commit modifies libghostty to use a single unified action
dispatch system based on a tagged union versus the one-off callback
system that was previously in place. This change simplifies the code on
both the core and consumer sides of the library. Importantly, as we
introduce new actions, we can now maintain ABI compatibility so long as
our union size does not change (something I don't promise yet).
Second, this moves a lot more of the functions call on a surface into
the action system. This affects all apprts and continues the previous
work of introducing a more unified API for optional surface features.
|
|
|
|
|
|
|
|
|
|
|
|
Temporarily change dependency sources to forks until they update
|
|
|
|
|
|
|
|
|
|
The GLFW build has grown farther and farther in feature parity with GTK
on Linux. And on macOS, the GLFW build has been unstable (crashes) for
months.
I still find the GLFW build useful for testing some core terminal work,
but it is increasingly user-hostile in case someone just downloads the
project and does a `zig build`.
I keep GLFW as up to date as I can, but the features that are missing
are due to fundamental limitations:
- GLFW has no tabs, splits, etc. because it has no UI elements.
I am not interested in painting UI widgets from scratch.
- GLFW cannot support keyboard layouts robustly because it has no
hooks to detect keyboard layouts or functions to get keymaps.
- GLFW cannot support the Kitty keyboard protocol because the
key/char API is too high level and it provides no low-level
alternatives.
- GLFW crashes on macOS under certain scenarios (this is my problem).
I'm not interested in fixing it because the AppKit-based build
is highly recommended.
To build or run the GLFW build you must now explicitly pass in
`-Dapp-runtime=glfw` to `zig build`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
