1 Topic by Daemonratte (edited by Daemonratte 2026-05-04 11:00:58)

  • Daemonratte
  • Daemonratte
  • Beginner
  • Offline
  • From: Mitteleuropa
  • Registered: 2026-05-04
  • Posts: 3

Topic: GTK2 revival

Hey Hyperbola community! big_smile

Some of you may have heard that GTK2 is being revived. Since Hyperbola already prefers GTK2 software, I thought this might be interesting here.

The repo is currently hosted on Devuan's Git server:
https://git.devuan.org/Daemonratte/gtk2-ng

The goal of gtk2-ng is simple: keep GTK2 alive, modernize the code where needed, fix compiler and deprecation warnings, and make sure it keeps building and working on modern systems.

The important part is that we do not want to break ABI. If a program built for vanilla GTK2 does not run properly with gtk2-ng, we consider that a bug in gtk2-ng.

There are also bigger plans around this. We want to revive GTK2-based versions of desktop environments like LXDE, GNOME 2 and XFCE, and also fork / maintain GTK2 versions of programs that moved away from GTK2, such as GIMP, Inkscape, AbiWord, Gnumeric, and others.

Another idea is to bring GtkMozEmbed back for Pale Moon's engine. That could make it possible to revive Galeon as a real GTK2 browser again.

This is still early work, but testing, feedback, ideas and patches would be very welcome.

Edit:
In case this helps with packaging for Hyperbola, someone already added gtk2-ng to the AUR:
https://aur.archlinux.org/packages/gtk2-ng-git

They seem to have applied a patch that was already merged on our side, though.

Daemonratte's Website

2 Reply by throgh

  • throgh
  • throgh
  • Package Development
  • Offline
  • From: Planet Earth
  • Registered: 2017-12-28
  • Posts: 3,135

Re: GTK2 revival

Hello and welcome to the forums. Thanks for noting as gtk2 is a beloved package for us also.

Personally I'm also excited to hear about the gtk2-based version of applications like GIMP, Inkscape, AbiWord and Gnumeric. Not only because I personally use them daily - okay for sure a major motivation for me - but foremost to be curious as packaging them together then with gtk2-ng. smile

Do you have plans / roadmap when a first stable release and tarball maybe available?

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

3 Reply by Daemonratte

  • Daemonratte
  • Daemonratte
  • Beginner
  • Offline
  • From: Mitteleuropa
  • Registered: 2026-05-04
  • Posts: 3

Re: GTK2 revival

Thanks!

I can't give a precise date for the first stable release or tarball yet, but gtk2-ng is already working very well in practice.

The current plan is to clean up the remaining compiler and deprecation warnings, and then do some more testing on GNU/Linux before calling it a first stable release. I hope this part should not take too long, maybe roughly around a month, but I don't want to promise an exact date yet.

You can already build and use gtk2-ng from git right now. Basilisk-dev tested it with his browser build and reported that it already feels noticeably faster than vanilla GTK2 in that use case:

https://forum.palemoon.org/viewtopic.ph … p;start=20

So I would say it is already in a very good state for testing and real-world feedback, even though I still want to do a proper first release/tarball instead of just calling the current git state “stable”.

Daemonratte's Website

4 Reply by throgh

  • throgh
  • throgh
  • Package Development
  • Offline
  • From: Planet Earth
  • Registered: 2017-12-28
  • Posts: 3,135

Re: GTK2 revival

So far I can see that there are reports with glib2 being not compiling on version 2.72.4. We have version 2.66.2.

A first dry run to use our packaging-script of gtk2 resulted in errors:

 |  autoreconf: export WARNINGS=
 |  autoreconf: Entering directory '.'
 |  autoreconf: running: autopoint --force
 |  Can't exec "autopoint": Permission denied at /usr/share/autoconf/Autom4te/FileUtils.pm line 293.
 |  autoreconf: error: autopoint failed with exit status: 13

This was tested with our current build-toolchain in a created chroot as we build everything on that way. I tried different ways but all resulted currently in errors leaving the packaging-process quit after preparation-steps. Furthermore we do not have dependencies like gtk-doc for example. We do not recognize such as needed therefore as man-pages should be enough for documentation. Do you have perhaps some steps ahead getting gtk-ng compiling from the git-version? Yes, I can try to build direct without a chroot-environment, but this is not the preferred way for us and leaves a questionmark if a package later on can be build in a clean build-environment.

Human being in favor with clear principles and so also for freedom in soft- and hardware!

Certainly anyone who has the power to make you believe absurdities has the power to make you commit injustices: For a life of every being full with peace and kindness, including diversity and freedom. Capitalism is destroying our minds, the planet itself and the universe in the end!

5 Reply by Daemonratte (edited by Daemonratte 2026-05-07 18:19:33)

  • Daemonratte
  • Daemonratte
  • Beginner
  • Offline
  • From: Mitteleuropa
  • Registered: 2026-05-04
  • Posts: 3

Re: GTK2 revival

Those reports are outdated. I added enough fallbacks until I was able to successfully compile gtk2-ng on Debian Jessie with GLib 2.42.1, so GLib 2.66.2 should be fine.

You can run configure with --disable-gtk-doc to avoid the gtk-doc dependency:

  ./configure --prefix=/usr --with-xinput=yes --disable-gtk-doc

For the other error I had to do a little research and also asked a chatbot for help. The suggestion was that this does not look like a gtk2-ng problem yet. It fails before configure because autoreconf cannot execute autopoint:

Can't exec "autopoint": Permission denied

Please check whether autopoint is executable inside the chroot:

  command -v autopoint
  ls -l "$(command -v autopoint)"

If it lacks the executable bit, this may fix it:

  chmod +x "$(command -v autopoint)"

If the chroot/build directory is mounted with noexec, it needs to be remounted without noexec.

P.S.
Sorry, I accidently pressed the wrong button at first (I pressed report tongue )

Daemonratte's Website