GNUstep integration

[pkgdemon]

Last Updated January 09 2026

Current Status

• Builds without errors on Debian Trixie ARM64 using RPI 500+ and builds hours faster than QT version in about 20 minutes!
• NSToolBar working
• Need to make all buttons use graphics instead of Unicode characters
• WebView now rendering proper coloring
• Fixed support for NSTabView
• Settings not working yet
• Help not working yet
• Address bar is a little unresponsive (to be fixed next)
• Need to fix ability to input text in web view
• YouTube does not play videos (does not work on macOS either)
• Tabs need to be switched to update titles
• Tab overview button current presents a list rather than a visual overview
• Needs proper CMAKE module to locate GNUstep
• Need to copy modified AppKit to new UI subfolder and separate GNUstep from AppKit
• The ladybird build system does not seem to generate app bundles (It was also this way for the Mac version before I started)
• I am looking into the possibility of building a windows version as well since GNUstep supports this, though this will move slower than other items above.
• Need to test a distribution that uses musl to see if vcpkg has to pull in glibc, and confirm whether or not gnustep compiled with CLANG can work with this toolchain.
• Need to determine how to handle pulling in GNUStep when GNUstep compiled with libobjc2 is not available for the distribution or determine if this can be made to support GCC without much effort.

Installation requirements

• FreeBSD not yet supported due to it being unable to build ICU. Seems to be upstream issue with vcpkg.
• Only Debian 13 Trixie working so far and Devuan 6.0 Excaliber

sudo apt install autoconf autoconf-archive automake build-essential ccache cmake curl fonts-liberation2 git libdrm-dev libgl1-mesa-dev libtool nasm ninja-build pkg-config python3-venv qt6-base-dev qt6-tools-dev-tools qt6-wayland tar unzip zip

I think we can safely omit qt6* packages as requirements but I need to determine what else is still required for GNUstep AppKit version

The Ladybird build documentation for CMake 3.25 or newer from KitWare does not work on ARM64, they do not have builds for Trixie ARM64. I skipped this.

Other requirements installed for testing were:

Note this repo did not have work for Devuan when I tried Devuan 6.0 Excalibur so I skipped these packages and the build worked anyway. I did have older clang installed however from gershwin-build.

# Add LLVM GPG signing key
sudo wget -O /usr/share/keyrings/llvm-snapshot.gpg.key https://apt.llvm.org/llvm-snapshot.gpg.key

# Optional: Verify the GPG key manually

# Use the key to authorize an entry for apt.llvm.org in apt sources list
echo "deb [signed-by=/usr/share/keyrings/llvm-snapshot.gpg.key] https://apt.llvm.org/$(lsb_release -sc)/ llvm-toolchain-$(lsb_release -sc)-20 main" | sudo tee -a /etc/apt/sources.list.d/llvm.list

# Update apt package list and install clang and associated packages
sudo apt update -y && sudo apt install clang-20 clangd-20 clang-tools-20 clang-format-20 clang-tidy-20 lld-20 -y

Audio support

sudo apt install libpulse-dev

I believe I installed this but configure still complains it cannot be found.

These are the steps to build and run ladybird using AppKit for GNUstep:

Bootstrap vcpkg

python3 Toolchain/BuildVcpkg.py

Configure with GNUstep support

CC=clang CXX=clang++ cmake --preset Release -DENABLE_QT=OFF

Build

cmake --build Build/release

Run

./Build/release/bin/Ladybird

[pkgdemon]

[cqundefine]

When it comes to FreeBSD, I actively work on support in upstream Ladybird and I have some PRs open both on the Ladybird side and vcpkg side, so if you wanna test that you can look through my open PRs. On FreeBSD icu fails due to an upstream issue and I have submitted a vcpkg PR, SDL3 fails, tho that only requires an upgrade in vcpkg.json. I also have patches fixing qtbase but I assume you don't need that :]

[pkgdemon]

When it comes to FreeBSD, I actively work on support in upstream Ladybird and I have some PRs open both on the Ladybird side and vcpkg side, so if you wanna test that you can look through my open PRs. On FreeBSD icu fails due to an upstream issue and I have submitted a vcpkg PR, SDL3 fails, tho that only requires an upgrade in vcpkg.json. I also have patches fixing qtbase but I assume you don't need that :]

Awesome. I mainly use FreeBSD myself so I will have a look for those PRs. :)

[ADKaster]

This is cool but pretty gnarly in the implementation (as expected from a prototype I suppose).

The CMake is a bit gross, I would hope that GNUStep would have a proper CMake module (or you could create a local Find module) that would let user code simply target_link_libraries(GNUStep::Core GNUStep::GUI) and call it a day.

The Platform.h header is also uncomfortable. the LADYBIRD_APPLE macro collies pretty heavily with AK_OS_MACOS that we already have in AK/Platform.h. The amount of macro ifdefs in your branch is also uncomfortable. If there's that much feature disparity between GNUStep and Apple's libraries, it's likely that a completely separate implementation in its own UI/ folder would be the sanest way to approach this idea.

One thing we've been driving towards in Ladybird is that if you have a cpp file that has a million ifdefs, try to split it into platform-specific files instead. it's okay if they have the same name/classes/etc, as we can control which impl is included via the build system. For the event loop especially, a separate GNUStep Event Loop impl seems appropriate. There's probably a lot of classes/views/models etc that can be shared between a macOS AppKit and GNUStep UI, but in the places where it doesn't work, a separate set of cpp/mm files would be preferred.

There's WIP work floating around for a GTK4 port by me that needs some vcpkg upstream help to get going again that might make it easier to 'slot in' a new UI/ folder on a fork than it is presently.

[pkgdemon]

This is cool but pretty gnarly in the implementation (as expected from a prototype I suppose).

The CMake is a bit gross, I would hope that GNUStep would have a proper CMake module (or you could create a local Find module) that would let user code simply target_link_libraries(GNUStep::Core GNUStep::GUI) and call it a day.

The Platform.h header is also uncomfortable. the LADYBIRD_APPLE macro collies pretty heavily with AK_OS_MACOS that we already have in AK/Platform.h. The amount of macro ifdefs in your branch is also uncomfortable. If there's that much feature disparity between GNUStep and Apple's libraries, it's likely that a completely separate implementation in its own UI/ folder would be the sanest way to approach this idea.

One thing we've been driving towards in Ladybird is that if you have a cpp file that has a million ifdefs, try to split it into platform-specific files instead. it's okay if they have the same name/classes/etc, as we can control which impl is included via the build system. For the event loop especially, a separate GNUStep Event Loop impl seems appropriate. There's probably a lot of classes/views/models etc that can be shared between a macOS AppKit and GNUStep UI, but in the places where it doesn't work, a separate set of cpp/mm files would be preferred.

There's WIP work floating around for a GTK4 port by me that needs some vcpkg upstream help to get going again that might make it easier to 'slot in' a new UI/ folder on a fork than it is presently.

Thanks @ADKaster I suspected a seperate new UI folder would be the better way to go for proper PR. I mostly did this way at first as an exercise to see which existing AppKit APIs would just work, and which would not as well. I will work towards something cleaner in a separate UI/ folder structure soon. I should work to get a proper toolbar, and rendering fixes in place first.

Truth be told I don't know CMAKE very well, and it certainly shows here. I will look into a module, and discuss with other GNUstep developers to see if we can come up with something nicer for that part. I also wasn't aware of a separate GTK porting effort I will have a look for that to get more familiar as a reference for how to add something more cleanly for the GNUstep effort here.

It sounds like the ladybird project might generally be warm to this kind of contribution, as long as the proper work is done to integrate nicely with the existing build system, in a non intrusive way? I could offer to make CI to monitor, maintain this portion as well if I can get a general consensus that it could be accepted once it is more proper of course.

[pkgdemon]

When it comes to FreeBSD, I actively work on support in upstream Ladybird and I have some PRs open both on the Ladybird side and vcpkg side, so if you wanna test that you can look through my open PRs. On FreeBSD icu fails due to an upstream issue and I have submitted a vcpkg PR, SDL3 fails, tho that only requires an upgrade in vcpkg.json. I also have patches fixing qtbase but I assume you don't need that :]

@cqundefine I noticed it looked like vcpkg icu fix was merged, but FreeBSD still would not build icu for me? I couldn't see any specific open PRs on ladybird side other than qt fixes? Does that have additional fixes to make the vcpkg build icu on freebsd 15.0 or is there another I am not finding?

[cqundefine]

When it comes to FreeBSD, I actively work on support in upstream Ladybird and I have some PRs open both on the Ladybird side and vcpkg side, so if you wanna test that you can look through my open PRs. On FreeBSD icu fails due to an upstream issue and I have submitted a vcpkg PR, SDL3 fails, tho that only requires an upgrade in vcpkg.json. I also have patches fixing qtbase but I assume you don't need that :]

@cqundefine I noticed it looked like vcpkg icu fix was merged, but FreeBSD still would not build icu for me? I couldn't see any specific open PRs on ladybird side other than qt fixes? Does that have additional fixes to make the vcpkg build icu on freebsd 15.0 or is there another I am not finding?

The versions of packages are fixed in the vcpkg.json file, you need to switch icu to 78.1#1 as that contains the fix. While you're at it you probably need to update SDL3 as the version currently set there doesn't build on FreeBSD, qtbase also doesn't build but you could just get rid of that. It'll also probably complain about the versions are not found so need to update the builtin-baseline field to a newer commit of the vcpkg repo. If you need any more help feel free to ask here!

[pkgdemon]

Thank @cqundefine I pulled in the fixes from your freebsd-timezone branch which it seems is a little behind upstream:

#3

It's only the first issue there that seems to affect the QT build as well, and workaround is documented. I'm wondering if when you sync from upstream you might see it as well, or maybe you are aware already.

[probonopd]

Hi @pkgdemon, this is a big achievement.

Trying to build on my RPi 5 on Devuan 6 (excalibur) I am getting errors with

# Use the key to authorize an entry for apt.llvm.org in apt sources list
echo "deb [signed-by=/usr/share/keyrings/llvm-snapshot.gpg.key] https://apt.llvm.org/$(lsb_release -sc)/ llvm-toolchain-$(lsb_release -sc)-20 main" | sudo tee -a /etc/apt/sources.list.d/llvm.list

Do you happen to know the procedure here?
Thanks.

[pkgdemon]

sudo apt install autoconf autoconf-archive automake build-essential ccache cmake curl fonts-liberation2 git libdrm-dev libgl1-mesa-dev libtool nasm ninja-build pkg-config python3-venv qt6-base-dev qt6-tools-dev-tools qt6-wayland tar unzip zip

python3 Toolchain/BuildVcpkg.py

CC=clang CXX=clang++ cmake --preset Release -DENABLE_QT=OFF

cmake --build Build/release

@probonopd Did you try at least these steps mentioned above? I believe you should be able to skip "qt6-base-dev qt6-tools-dev-tools qt6-wayland" but I've not dug in deep to see if the build system checks for them. If you did try all of the above which command specifically triggered the message?

[pkgdemon]

At first I initially ran this as well after sudo apt install autoconf autoconf-archive automake build-essential ccache cmake curl fonts-liberation2 git libdrm-dev libgl1-mesa-dev libtool nasm ninja-build pkg-config python3-venv qt6-base-dev qt6-tools-dev-tools qt6-wayland tar unzip zip:

# Add LLVM GPG signing key
sudo wget -O /usr/share/keyrings/llvm-snapshot.gpg.key https://apt.llvm.org/llvm-snapshot.gpg.key

# Optional: Verify the GPG key manually

# Use the key to authorize an entry for apt.llvm.org in apt sources list
echo "deb [signed-by=/usr/share/keyrings/llvm-snapshot.gpg.key] https://apt.llvm.org/$(lsb_release -sc)/ llvm-toolchain-$(lsb_release -sc)-20 main" | sudo tee -a /etc/apt/sources.list.d/llvm.list

# Update apt package list and install clang and associated packages
sudo apt update -y && sudo apt install clang-20 clangd-20 clang-tools-20 clang-format-20 clang-tidy-20 lld-20 -y

I found out that /etc/apt/sources.list.d/llvm.list does not work with Devuan Excalibur so I removed that file and skipped sudo apt update -y && sudo apt install clang-20 clangd-20 clang-tools-20 clang-format-20 clang-tidy-20 lld-20 -y. Does python3 Toolchain/BuildVcpkg.py check for the installed gpg key in keyring perhaps?

[cqundefine]

Need to test a distribution that uses musl to see if vcpkg has to pull in glibc, and confirm whether or not gnustep compiled with CLANG can work with this toolchain.

FWIW, I've tried testing on Void Linux x86_64 with the musl libc quite recently, but run into linking errors at the end and I haven't yet gotten around to fixing those yet. Vcpkg itself does work on musl and I've modified the script upstream to pull the musl version of vcpkg so that should work without any changes.

[pkgdemon]

After the Gershwin Desktop environment presentation we did a live demo of Ladybird running on Gershwin here https://m.youtube.com/watch?v=DDwLzy8map8