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.
Gtk2 also had exceptionally long lifetime, initial release in 2002 and last release in 2020. In contrast Gtk1 was initially released in 1998 and last release was 2001.
Motif was the real "classic" API. But let's do a little justice to GTK1. Motif was still a proprietary library when GTK1 was released. GTK1 was also already easier to develop with, and the default look&feel was somehow better. For some reason, all the widgets in the Motif UI were huge. Given the small resolutions of that time, it was very space inefficient.
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.
Oh, yes, I remember those early times as well. :)
The question is whether it's possible to maintain the legacy API and upgrade the internal architecture to use more modern approaches. I think it's almost always possible, but perhaps the cost to develop and maintain such a legacy layer is too high for an open-source desktop environment and toolkit. The Windows OS managed to support old APIs quite well, but the available resources are incomparable.
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.
Somewhat tangential: Is there a lightweight distribution of GTK2? I was shopping for a cross-platform GUI library with a C API, and GTK2 seemed like the right choice. But the Windows distribution [1] had 30-40 DLLs and none of them seemed to be optional in DependencyWalker.
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?
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.
IMO Gtk2 is better than Gtk1 as it did a significant number of improvements both in terms of features and usability. Later versions though aren't as great.
And TBH i do not think Gtk was ever "great", it was just fine and its main feature was availability because of the C API. For some time it was also the de-facto GUI API (during Gtk2 times) for Linux until Gtk3 broke that.
I wouldn't say that maintainers break API, "for no reason at all", but surely they don't make the stable API a priority either. The fact is, that every API breaking change is an insult to developers/users of that API. But this is an unfortunate state of the Linux desktop.
Yes, no reason at all. I submit as evidence gtk_hbox_new(), there since the very first version of GTK, and deprecated in 3.2, in favor of gtk_box_new(GTK_ORIENTATION_HORIZONTAL).
It's a prime example of something that was entirely unnecessary, could have been hidden from the user with a macro, or (pointlessly) added but keeping the old API in place.
They do this all the time. It's not just the idiocy, it's the blatant hostility towards their users that gets me.
This is sad. Actually, a long time ago I stopped working on two Linux desktop applications that used KDE framework libraries. I managed to port them from KDE1 to KDE2, but I got frustrated and lost my patience with KDE3 changes which had nothing to do with my application and I just gave up. Sorry to hear that GTK is the same constantly changing target.
After this experience I actually like Web-UIs and CLI apps a lot more.
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.
GTK doesn't implement garbage collection, you need to clean up by destroying widgets and other resources that you have created. Of course, the operating system will free all resources used by your process when it ends, so that kind of final cleanup is often omitted (and even more so in example code).
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.)
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.
Yeah, I think GTK2 would be a better candidate to keep maintaining. GTK3 is where it started to go to hell in a handbasket.
Gtk2 also had exceptionally long lifetime, initial release in 2002 and last release in 2020. In contrast Gtk1 was initially released in 1998 and last release was 2001.
The "classic API" would probably be Xaw or Motif. Those haven't changed since practically before there was Linux.
Motif was the real "classic" API. But let's do a little justice to GTK1. Motif was still a proprietary library when GTK1 was released. GTK1 was also already easier to develop with, and the default look&feel was somehow better. For some reason, all the widgets in the Motif UI were huge. Given the small resolutions of that time, it was very space inefficient.
Then I would vote for Motif. But since it predates Linux, it is a classic Unix look, not Linux. For the younger crowd: <https://en.wikipedia.org/wiki/Motif_(software)>
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.
Oh, yes, I remember those early times as well. :) The question is whether it's possible to maintain the legacy API and upgrade the internal architecture to use more modern approaches. I think it's almost always possible, but perhaps the cost to develop and maintain such a legacy layer is too high for an open-source desktop environment and toolkit. The Windows OS managed to support old APIs quite well, but the available resources are incomparable.
Motif was improved with XFT/Fontconfig support. GTK1 can be patched too'
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/
Somewhat tangential: Is there a lightweight distribution of GTK2? I was shopping for a cross-platform GUI library with a C API, and GTK2 seemed like the right choice. But the Windows distribution [1] had 30-40 DLLs and none of them seemed to be optional in DependencyWalker.
[1] https://github.com/tschoonj/GTK-for-Windows-Runtime-Environm...
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?
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.
IMO Gtk2 is better than Gtk1 as it did a significant number of improvements both in terms of features and usability. Later versions though aren't as great.
And TBH i do not think Gtk was ever "great", it was just fine and its main feature was availability because of the C API. For some time it was also the de-facto GUI API (during Gtk2 times) for Linux until Gtk3 broke that.
I wouldn't say that maintainers break API, "for no reason at all", but surely they don't make the stable API a priority either. The fact is, that every API breaking change is an insult to developers/users of that API. But this is an unfortunate state of the Linux desktop.
Yes, no reason at all. I submit as evidence gtk_hbox_new(), there since the very first version of GTK, and deprecated in 3.2, in favor of gtk_box_new(GTK_ORIENTATION_HORIZONTAL).
It's a prime example of something that was entirely unnecessary, could have been hidden from the user with a macro, or (pointlessly) added but keeping the old API in place.
They do this all the time. It's not just the idiocy, it's the blatant hostility towards their users that gets me.
This is sad. Actually, a long time ago I stopped working on two Linux desktop applications that used KDE framework libraries. I managed to port them from KDE1 to KDE2, but I got frustrated and lost my patience with KDE3 changes which had nothing to do with my application and I just gave up. Sorry to hear that GTK is the same constantly changing target. After this experience I actually like Web-UIs and CLI apps a lot more.
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/
`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!
Tried to build on Windows, Mac, Linux: different errors on each platform.
Is Glade unmaintained nowadays? The last release is 3 years old.
Ubuntu doesn’t ship libgtk1.2 anymore in standard repositories.
I like GTK but......
small example have error (memory leak) in valgrind
Without further detail, that's not very helpful.
GTK doesn't implement garbage collection, you need to clean up by destroying widgets and other resources that you have created. Of course, the operating system will free all resources used by your process when it ends, so that kind of final cleanup is often omitted (and even more so in example code).
GTK1 is the best GTK.