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.
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.
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.
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.
Are you sure no antialiasing? No subpixel for sure.
I think I have some rusty memory of LD_PRELOAD my own .so with AA enabled (special patch? I don’t recall) with a game’s installer I shipped to get the statically linked GTK+1.2 Loki Games setup utility looking modern. That plus a QUITE SPIFFY looking splash bitmap slapped onto it would hopefully let the installation complete before anyone realized it was a creaky old thing.
Did it? I can't find documentation that suggest it returned antialiased font data. The server could of course request a larger font size and scale it down, but did any do that?
I'm not questioning that it'd be possible to render antialiased fonts server side as there's nothing in X that really prevent it, I just don't recall that being a thing, rather than upgrading apps to use Xrender to render fonts client side and send the servers and atlas of pre-rendered glyphs the way we currently do.
I could very well be wrong - I didn't do much X programming in the brief period it'd have been relevant.
Thanks for the pointer, but from the page you linked to:
> Even though xfstt doesn't do any anti-aliasing of the fonts (since there's no support for this in X)
The page it links to for xfsft as well, says this:
> Although FreeType does support font smoothing, the modified libfont.a does not. Adding font smoothing to X would require a major change to the system: in X, glyphs are (monochrome) bitmaps, and there is no support for using pixmaps as glyphs. Changing this would require the design and implementation of an extension to both the X protocol and the font server protocol, and changing applications to use the extensions.
It goes on to link to the Xrender extension as a solution.
You were half right which is something for stuff this old. I'd entirely forgotten about the font servers, and looking at them, at least xfsft does use FreeType/Xft. It's just that it's still rendering to monochrome bitmaps.
It'd have been a logical extension to figure out the changes to support AA for them as well, so it's a reasonable assumption, especially given the short cutover before Xrender took over and we started getting AA most places. Indeed, Xrender provides all the server-side infra that'd have made it easy-ish to do, by allowing glyph sets with depth...
In retrospect it's also surprising that it wasn't done, because it wouldn't instantly given AA to a lot of applications "stuck" on server side font rendering...
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.
The free clone "LessTif" already existed when "GTK+" 1.x came along.
I agree that GTK was much easier to program, and had a better feel but the look was mimicking Motif except that every widget instead used a shaded button-style border — and that looked very ugly IMHO.
However, GTK 1.x supported theme engines. Back in the day, my theme for GTK 1.x was one of the most popular, giving programs a look reminiscent of NeXTStep and Windows 95.
The engine also (optionally) hacked the GTK widgets, adding triangular tabs and subtly improved menu behaviour. When GTK 2.0 came along, it had a much improved default look that felt like its own thing, and also the new menu behaviour so my theme wasn't needed any more.
Xaw was also really awful to program in. When I tried using it once I ended up reverting to just plain Xlib and was much happier, even having to build my own widgets out of low level primitives.
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.
But GP used client and server correctly, no? In the traditional model, the server renders the text it received from the client. Nowadays, the client renders it itself and pushes the whole bitmap to the server.
Yes? But older X code used to use server side font rendering. The move to client side is the new thing. So this still sounds like the original comment got it right, though I guess ordered in a way that might make it ambiguous.
Indeed, I probably could have made it more clear I was referring to the situation in Gtk 2, but I figured it was implicit given that, of Gtk 1 and Gtk 2, only the latter renders text in client-side pixmaps/pixbufs.
I don't get how it could be the other way around? The domain here is controlling a display. A server does stuff, a client requests it. The X naming is exactly natural. The server draws and controls hardware, the client requests it.
On traditional GUIs nomeclature (not X), client is what is running on the local hardware, server is where the actual process is running, aka thin clients.
It is also the nomenclature when talking about RDP, VNC, and many others,
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.
It's mostly because we have different aspects ratios and resolutions now, but also things like accessibility play a role. You're happy to use simple UI toolkits, but you'll very quickly realize it doesn't look good when someone resizes the app
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.
Deprecated does not mean removed. Was there any actual API/ABI changes in GTK3?
Also, it is easy to call people idiots, but calling people who GIVE you software you can choose to use or not that is not very productive or even nice.
I could call you names but that would only make this discussion worse.
I absolutely share your frustration at breaking API changes, and the older I (and my software) gets, the more it irritates me. It can be downright enraging to have (my) perfectly working code suddenly broken due to an irrelevant (to me) API change, especially when it requires hunting down a ton of compiler errors. I absolutely wish they would prioritize stability more.
Now that said, I do not think the truth is "The maintainers seem to go out of their way to break API, for no reason at all" or "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." Having worked on numerous long-lived APIs in the past, there is always a tension between backwards compatibility and future development, especially consistency between calls. Especially when there are a lot of different contributors, it's very easy for annoying inconsistencies to pop up, and it feels really great to fix those. It's a constant balancing act between the past and the future, and a tilt too far in one direction comes with some significant downsides. I also think some grace is warranted for people giving their code away freely with no expectation in return.
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.
Yes, this is a prime example of completely gratuitous breakage.
The change adds zero value. It's a deliberate API break. And it could have been made a non-breaking change all for the sake of a single one-line macro or inline function.
This isn't unintentional. It's a deliberate choice they have made. And not just this one, it's happened repeatedly over the years.
The thing that really gets me, as an end-user/developer, is that it forces incompatible changes not only in my codebases, but in every other application developer's codebases worldwide. A small change in GTK+ imposes hundreds of thousands of man-hours of maintenance work upon every application developer. And this burdensome work not only takes time, effort and money, it doesn't improve our applications one iota, and on top of that, it breaks backward compatibility so our code will not longer build with older GTK+ versions. Most of us won't be chasing the latest development release, applications might need to target a wide range of distributions with a wide range of GTK+ versions. So it's a logistical nightmare as well.
The lack of concern for the needs of actual application developers is why I eventually had to give up on it entirely. At some point it doesn't make any sense either commercially or for free software development, it's just masochism.
I completely agree. This comment should be carved in stone for future generations to see. API breaking changes should never be made just to chase illusory butterflies.
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).
GTK intentionally doesn't calls free, unless some debug symbol is called. This is to prevent trashing before exiting, but is annoying when targeting correctness.
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.
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/
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.
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.
Are you sure no antialiasing? No subpixel for sure.
I think I have some rusty memory of LD_PRELOAD my own .so with AA enabled (special patch? I don’t recall) with a game’s installer I shipped to get the statically linked GTK+1.2 Loki Games setup utility looking modern. That plus a QUITE SPIFFY looking splash bitmap slapped onto it would hopefully let the installation complete before anyone realized it was a creaky old thing.
Oh yes. I present you gtkaa:
https://web.archive.org/web/20231129124306/http://alx14.free...
…and recompile mozilla and nautilus and maybe all other stuff using gtk1…
As someone who used to build Mozilla suite back when their gtk2 support was experimental, I’d say this is too much faff.
GTK 1.x used GDK which was a thin veneer on top of Xlib, and I think it defaulted to use Xlib calls for text rendering.
If the X server supported antialiased text (and subpixel rendering) then GTK should have done too.
Do any X servers do? Antialiased text on X is generally done by rendering the glyphs client side.
They did with the XFT font server?
https://en.m.wikipedia.org/wiki/X_Font_Server
Did it? I can't find documentation that suggest it returned antialiased font data. The server could of course request a larger font size and scale it down, but did any do that?
I'm not questioning that it'd be possible to render antialiased fonts server side as there's nothing in X that really prevent it, I just don't recall that being a thing, rather than upgrading apps to use Xrender to render fonts client side and send the servers and atlas of pre-rendered glyphs the way we currently do.
I could very well be wrong - I didn't do much X programming in the brief period it'd have been relevant.
Back in the day there was a font server for antialiased fonts, xfstt:
https://tldp.org/LDP/LG/issue28/ayers1.html
That was what I was looking for.
Thanks for the pointer, but from the page you linked to:
> Even though xfstt doesn't do any anti-aliasing of the fonts (since there's no support for this in X)
The page it links to for xfsft as well, says this:
> Although FreeType does support font smoothing, the modified libfont.a does not. Adding font smoothing to X would require a major change to the system: in X, glyphs are (monochrome) bitmaps, and there is no support for using pixmaps as glyphs. Changing this would require the design and implementation of an extension to both the X protocol and the font server protocol, and changing applications to use the extensions.
It goes on to link to the Xrender extension as a solution.
Well, my fault again. I remember a daemon doing XFT rendering for plain X, from Debian Woody days.
You were half right which is something for stuff this old. I'd entirely forgotten about the font servers, and looking at them, at least xfsft does use FreeType/Xft. It's just that it's still rendering to monochrome bitmaps.
It'd have been a logical extension to figure out the changes to support AA for them as well, so it's a reasonable assumption, especially given the short cutover before Xrender took over and we started getting AA most places. Indeed, Xrender provides all the server-side infra that'd have made it easy-ish to do, by allowing glyph sets with depth...
In retrospect it's also surprising that it wasn't done, because it wouldn't instantly given AA to a lot of applications "stuck" on server side font rendering...
Motif was improved with XFT/Fontconfig support. GTK1 can be patched too'
I wonder how many llm tokens are burned dealing with Unicode issues?
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.
The free clone "LessTif" already existed when "GTK+" 1.x came along.
I agree that GTK was much easier to program, and had a better feel but the look was mimicking Motif except that every widget instead used a shaded button-style border — and that looked very ugly IMHO.
However, GTK 1.x supported theme engines. Back in the day, my theme for GTK 1.x was one of the most popular, giving programs a look reminiscent of NeXTStep and Windows 95. The engine also (optionally) hacked the GTK widgets, adding triangular tabs and subtly improved menu behaviour. When GTK 2.0 came along, it had a much improved default look that felt like its own thing, and also the new menu behaviour so my theme wasn't needed any more.
If I remember correctly, Xaw was part of X and predated Motif although it’s hard to really call Xaw a full UI; it was pretty bare bones and limited.
It’s worth keeping in mind that there were other Unix UIs that didn’t make it. For example, Sun NeWS was quite interesting (based on PostScript).
> For some reason, all the widgets in the Motif UI were huge.
Huge and IMO quite ugly. Also slow. Not that Xaw was pretty ( or even that functional). GTK1 was definitely a step in the right direction.
Xaw was also really awful to program in. When I tried using it once I ended up reverting to just plain Xlib and was much happier, even having to build my own widgets out of low level primitives.
Both Motif and Xaw were configurable with XResources, they could be as big and small as you wanted.
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)>
OpenLook/XView is contemporary as well. And CDE is a thing, still.
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.
You actually hit the nail on the head; pixbuf/pixmap font rendering on the client side rather than X server side text rendering.
Note that on X, client and server are inverted.
But GP used client and server correctly, no? In the traditional model, the server renders the text it received from the client. Nowadays, the client renders it itself and pushes the whole bitmap to the server.
Pushing the whole bitmap is much slower over dialup, versus a set of commands.
Yes? But older X code used to use server side font rendering. The move to client side is the new thing. So this still sounds like the original comment got it right, though I guess ordered in a way that might make it ambiguous.
Indeed, I probably could have made it more clear I was referring to the situation in Gtk 2, but I figured it was implicit given that, of Gtk 1 and Gtk 2, only the latter renders text in client-side pixmaps/pixbufs.
I'm not disagreeing with you. I'm merely pointing out that you're not disagreeing with GP either.
I don't get how it could be the other way around? The domain here is controlling a display. A server does stuff, a client requests it. The X naming is exactly natural. The server draws and controls hardware, the client requests it.
On traditional GUIs nomeclature (not X), client is what is running on the local hardware, server is where the actual process is running, aka thin clients.
It is also the nomenclature when talking about RDP, VNC, and many others,
https://en.m.wikipedia.org/wiki/Remote_desktop_software#
I'm aware. The X server is the thing the user sits and operates. I've written quite a bit of Xlib code in my day.
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'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.)
It's mostly because we have different aspects ratios and resolutions now, but also things like accessibility play a role. You're happy to use simple UI toolkits, but you'll very quickly realize it doesn't look good when someone resizes the app
Tk usually looks good when resizing the app. Much better than any of the quintuply queued and buffered windows stuff anyhow
[dead]
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.
Deprecated does not mean removed. Was there any actual API/ABI changes in GTK3?
Also, it is easy to call people idiots, but calling people who GIVE you software you can choose to use or not that is not very productive or even nice.
I could call you names but that would only make this discussion worse.
> The maintainers seem to go out of their way to break API, for no reason at all. That extends to Gnome applications as well.
This is also true for KDE and, unfortunately, a lot of modern software. People just don't like building and fixing things.
I absolutely share your frustration at breaking API changes, and the older I (and my software) gets, the more it irritates me. It can be downright enraging to have (my) perfectly working code suddenly broken due to an irrelevant (to me) API change, especially when it requires hunting down a ton of compiler errors. I absolutely wish they would prioritize stability more.
Now that said, I do not think the truth is "The maintainers seem to go out of their way to break API, for no reason at all" or "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." Having worked on numerous long-lived APIs in the past, there is always a tension between backwards compatibility and future development, especially consistency between calls. Especially when there are a lot of different contributors, it's very easy for annoying inconsistencies to pop up, and it feels really great to fix those. It's a constant balancing act between the past and the future, and a tilt too far in one direction comes with some significant downsides. I also think some grace is warranted for people giving their code away freely with no expectation in return.
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.
Yes, this is a prime example of completely gratuitous breakage.
The change adds zero value. It's a deliberate API break. And it could have been made a non-breaking change all for the sake of a single one-line macro or inline function.
This isn't unintentional. It's a deliberate choice they have made. And not just this one, it's happened repeatedly over the years.
The thing that really gets me, as an end-user/developer, is that it forces incompatible changes not only in my codebases, but in every other application developer's codebases worldwide. A small change in GTK+ imposes hundreds of thousands of man-hours of maintenance work upon every application developer. And this burdensome work not only takes time, effort and money, it doesn't improve our applications one iota, and on top of that, it breaks backward compatibility so our code will not longer build with older GTK+ versions. Most of us won't be chasing the latest development release, applications might need to target a wide range of distributions with a wide range of GTK+ versions. So it's a logistical nightmare as well.
The lack of concern for the needs of actual application developers is why I eventually had to give up on it entirely. At some point it doesn't make any sense either commercially or for free software development, it's just masochism.
I completely agree. This comment should be carved in stone for future generations to see. API breaking changes should never be made just to chase illusory butterflies.
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.
Sounds like the work of architecture astronauts: https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
The best part is having no good alternative to the deprecated stuff.
In the end I just stopped giving a damn and use either a modified microui or lvgl.
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.
Judging from the commit history, i get the impression that commits are made regardless of if the library builds or not.
same here
I was about to make a Cinepaint joke, but it seems that's already been addressed.
Is Glade unmaintained nowadays? The last release is 3 years old.
They're working on something for GTK4 iirc
Ubuntu doesn’t ship libgtk1.2 anymore in standard repositories.
GTK1 is the best GTK.
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).
GTK intentionally doesn't calls free, unless some debug symbol is called. This is to prevent trashing before exiting, but is annoying when targeting correctness.
show me any example from oficial documentation gtk[1,2,3...] qt etc for no memory leak in valgrind
[dead]