19 comments

[ 2.6 ms ] story [ 34.8 ms ] thread
I never followed the history of GTK very much but reading about non-compatibility between versions surprises me, just as a matter of software engineering re a critical dependency.

I am unsure from the page, just that it implied: is there software in 2025 still using GTK v1?

`apt search libgtk` on Linux Mint 21.2 doesn't show it. Only versions 2, 3 and 4.

Searching https://pkgs.org says that most distros don't have a gtk 1 package... except for Slackware!

Lazarus[0] has a Gtk 1.2 backend that i occasionally fix (though it has been a while since i tested it), but you need to install the Gtk 1.2 libraries from source[1] since no current distro aside from Slackware (from where i got the sources and patches) packages it. Even Slackware though doesn't provide gdk_pixbuf (which Lazarus needs) though, so you'd need to compile that.

I'm not sure if GTK1 (the linked one) is backwards and/or binary compatible with Gtk 1.2 though.

[0] https://www.lazarus-ide.org/

[1] http://runtimeterror.com/pages/badsector/gtk12/

The non-compatibility has over the years become the defining feature of GTK/Gnome. The maintainers seem to go out of their way to break API, for no reason at all. That extends to Gnome applications as well.

I recently found a GTK API call that was deprecated in GTK 3.0, only for its replacement to be deprecated by 3.16. These are not thoughtful people, with a vision for the future. They are idiots that inherited something great (GTK 1), and have spent decades thoroughly fucking it up.

Nice to see that someone is still maintaining the original GTK1 toolkit. It's like the classic Win32 UI API for the Linux/Unix. Linux UI libraries are a constantly moving target and one can be easily more occupied by adapting to those toolkit API changes instead of focusing on the features of the application itself. I guess that CinePaint developers decided at some point that they don't want to endure API changes in the UI toolkit anymore.

On the other hand, I think GTK1 doesn't even support Unicode.

It doesn't support Unicode, doesn't support font antialiasing, and instead of fontconfig, you need to grapple with X11 core font support, using ttmkfdir and friends, and make the X11 server aware of where the fonts are.

It's some experience I definitely don't miss from those days.

The "classic API" would probably be Xaw or Motif. Those haven't changed since practically before there was Linux.
Is it binary backwards compatible with Gtk1.2? AFAICT from the description it seems to be based on Gtk1.2 but it is its own thing.

I've being using Gtk 1.2 + patches[0] (which i made by combining the last release with a few patches from Slackware) to occasionally check Lazarus' Gtk1 support. It is also neat if you want to make self-contained binaries, for example this little animation utility i wrote some time ago[1] has a Gtk1-based build with Gtk1 linked statically on it and the tool relying on just X11 and OpenGL.

[0] http://runtimeterror.com/pages/badsector/gtk12/

[1] http://runtimeterror.com/tools/piecemod/

I like GTK but......

small example have error (memory leak) in valgrind

Is Glade unmaintained nowadays? The last release is 3 years old.
Tried to build on Windows, Mac, Linux: different errors on each platform.
Ubuntu doesn’t ship libgtk1.2 anymore in standard repositories.
I'm so happy to know this exists because every single cross-platform UI toolkit I've used in the past few decades is more complex and weird.

(Not that GTK1 can't be complex and weird, more that we've lost the art of creating native GUI toolkits that make sense.)

I was about to make a Cinepaint joke, but it seems that's already been addressed.
One thing that GTK lost in the transition to GTK2 was working well over slow Internet connections. I remember how even on a dial up modem you got pretty acceptable performance out of a GTK1 app, so long as it wasn't shoving big bitmaps around. GTK2 on the other hand was always dog slow over remote X connections for no apparent reason.
Thank you! Nice that people care about my work on GTK1. I haven't announced a GTK1 release, so don’t expect it to be stable yet.

GTK1 interests me as it is necessary to build retro apps I like. CinePaint being one, and also dozens of other classic GTK apps. A technical reason to care about GTK1 is code size. GTK2 is much larger than GTK1. GTK3 is much larger than GTK2.

> it seems to be based on Gtk1.2 but it is its own thing.

Yes. Historically, GTK1 was maintained as 3 separate projects across the 3 major operating systems by three different teams, not a single codebase. I created the Windows port. Later I took over the MacOS port that someone had started, but had abandoned before completion. After gtk.org deprecated Linux GTK1, I took on that code, too.

As I combine code from different versions of GTK1 from different operating systems, it breaks things. My current effort is to complete integration of the MacOS and Linux code with my Windows code, and remove resultant bugs.

> maintain the legacy API and upgrade the internal architecture to use more modern approaches.

GTK1 is of a GTK 1.2 flavor plus some enhancements. Yes, I want to smooth off old rough edges, to make GTK1 better with fonts and pixbuffers.

> I present you gtkaa [GTK1 anti-aliasing patch]

Thank you! Will take a stab at integrating that. I previously integrated the GTK1 dark-mode patch. If there are other interesting GTK1 patches in the archives somewhere, let me know. I’ve heard that gtk.org wasn’t very welcoming to GTK1 patches.

> Is there a lightweight distribution of GTK2?

Maybe in the future.

CinePaint conditionally compiled with GTK1 or GTK2 using an #ifdef. Not a lot of changes to make it build either as GTK1 or GTK2. The GTK2 API broke GTTK1 compatibility in some silly ways. For example, changing the order or arguments in function calls of the same name. Or, making an API that took one call in GTK1 take 2 calls in GTK2, or vice versa. Minor stuff, at least in the calls used by CinePaint.

Are other GTK1 apps as easy to port to GTK2 as was CinePaint? I want to add common GTK2 APIs to GTK1 to see how that goes. Doing so would make GTK1 into a very lightweight implementation of the GTK2 API.