Other/future projects • Re: GTK2 revival

Yes, we're not upset by your reaction, but I do want to clarify something. We're not just "keeping the past alive for oldschool reactionaries who want things to stay the way they are". Think of gtk2-ng as being what Pale Moon is to Firefox. Pale Moon isn't an ancient browser engine with patches to compile it on modern systems. It's an up-to-date browser engine with a different philosophy. We like gtk2 and we want to give it the same treatment you guys gave to UXP and Goanna. We want gtk2 to become a modern cross-platform toolkit that runs well on modern and old hardware alike. We want to to define what is modern. We want to be the future. We want your browsers and your amazing email client to be the future. We can make it the future.

Ah, I see... so you really DO hope this becomes the next Cinnamon or MATE style revolution, at least toolkit-wise? And you're still hoping for distro buy-in. Thanks for clarifying. I'd honestly have to say... if you guys think appealing to us is a good way to get Linux distros to like you, or you think we must have pull with them because we're an older and more established project that has survived for this long without rebasing on something newer, you might be barking up the wrong tree. Let's just say there's a reason why we tend to package our software as tar.gz, distrust system libs, and encourage people to unpack our binaries to their home directory rather than rely on their distros to ship our binaries in their repos like other Linux software does. To put it bluntly, Linux distros usually are not big fans of us (though I think there are maybe a handful of exceptions). Just fair warning.

We didn't survive by convincing distros to accept Pale Moon in their repos. We survived by compiling and shipping generic enough binaries that most Linux users could run them, and the few that couldn't (usually people on non-glibc Linux) could compile the codebase easily. But as a toolkit, you guys will not have the same luxury. You pretty much NEED distro buy-in, and you need application developer buy-in as well. That's harder in some ways than shipping a UXP application like Pale Moon, because we can just adapt ourselves to our environment (sometimes slowly and painfully) and keep going regardless of how commonly used we are, or whether distros like us, rather than convincing people to target us specifically. And if you're having trouble selling me on it, someone that's in a desperate enough situation that it even sounds beneficial for two seconds... I can only imagine what people who have fully functional GTK3 or even GTK4 ports of their applications already would think of the same pitch.

We don't want this to be some nice-to-have nostalgic sideproject. We want to turn this into a toolkit that's going to be used for brand new software, available in as many distro repos as possible. If we can convince the Ardour team to use our toolkit and make it easier for developers to migrate to our toolkit instead of gtk4 then it will stay. We can then highly boost your engine's market share by making it the default for all the software we're going to modernise.

I do believe you when you say this outcome is what you want (otherwise why do all that work?), and I completely understand the ambition. It's just... even if you work hard and make this the best it can be. Even if it really is better than GTK4 in every way. There's a really good chance distros will say no anyway. The reason why is that GTK2 is an X11 only toolkit, and a fairly complex one with a lot of moving parts at that. Distros aren't dropping Motif, but GTK2 is a different animal. In 2026, distros want something that can at least support Wayland as far as toolkits and desktops go. It's why MATE and Cinnamon are driving themselves crazy trying to do Wayland ports, they don't want distros to see them as X11 only and drop them. Cross-platform applications (like us) can still get away with targeting XWayland for quite a while probably, but something like a toolkit or a DE needs to support both X11 and Wayland because of where the ecosystem is right now, just to be taken seriously. Maybe some distros would be open if they are shipping XOrg or one of its forks as default still, and seem like they are rejecting Wayland out of hand... the rest will likely steer clear if only because of the optics of a toolkit that explicitly rejects Wayland and the alignments that implies. Even if you do modernize it, distros won't see modern... the name GTK2 kind of precludes that. People will immediately think of the thing that hasn't gotten security updates in 6 years when they hear that name.

Also, I remember The_Squash. His project was called "STLWRT" and yeah, he did want to merge gtk2 and 3, but you would have had to compile all your software again for that. Our goal is to stay binary compatible.

Yeah, that's right. It sounds like you may have been inspired by the idea somewhat. It's a small world after all, LOL.

But yeah, I have no illusions about what it is we are doing here. The primary goal is to keep XUL extensions and theming alive, I believe. In some ways, we are maintaining an old browser engine (and extending it beyond its original limits), because the new one doesn't support our use cases any longer. We have an older CSS parser that Firefox dropped for a Rust-based one, for instance. We maintain tighter integration with XPCOM, XPIDL, XUL, XBL and other technologies. Goanna carries forward a lot of old Gecko code. By a lot of metrics, that is an "old browser engine" because none of that is maintained by Firefox anymore. But still, a lot of code gets backported from Mozilla, security vulnerabilities get patched, a lot of new work gets done to support web standards, and at this point there's even been work on low-level platform code and the build system. And most importantly... we don't guarantee full backwards compatibility with all XUL extensions that were developed for Firefox. As we move forward with the JS engine work, sometimes extension maintainers have to update their code. That's what it means to have a living ecosystem. If you have to maintain binary and API compatibility with GTK2 forever, then what you're developing can't really grow beyond simply being a security-hardened GTK2 with some speed improvements, and maybe a few extras that don't break anything.

What we're preserving is XUL as an API to an extent, but more importantly the flexibility to extend the browser in a more abstract sense, but definitely not making sure everything runs exactly as it did without modification. Sometimes changes break themes or extensions, updates are needed. Sometimes something like moving to GTK3 (or probably another toolkit in the future) would also break a theme or two, again we expect them to adapt and follow us. There is an element of truth to "maintaining an old browser engine," but we replace things as they wear out and don't guarantee backwards compatibility forever, so eventually this may well become so much its own thing that it's not even recognizable, eventually through "Ship of Theseus" logic no longer being the same ship, so far from the original that it has its own ecosystem. A GTK2 fork... really can't diverge much while still being interesting to people with applications that targeted GTK2.

But yeah, I do wish you luck... I just hope you aren't overestimating your chances of success or misreading the incentives in the Linux ecosystem, thinking it's easier to get distros to change their mind or accept you as a replacement for their original upstream than it really is.