[_d7dt]

I've posted about this before, but if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen. I'm not sure what "reputation" you're referring to but if GTK does not meet your needs, and Qt (or something else) does, then I think that's great for you, you should just use that.

[entropy1111]

GNOME being slow and not having basic features like thumbnails in the file picker after almost 18 years was often attributed, by their maintainers, to be caused by GTK3 limitations. Even now Glade still needs a lot of "volunteering" to be production ready for GTK3. I don't use GTK anymore, this is my opinion after reading a lot about it and seeing recommendations like "if you need documentation just read existing code", "why is Glade missing X or Y? just copy some XML node, just edit the XML and pray".

Anyway who cares, maybe GTK4 is good and new GTK threads will not be full of people talking about how bad it was. But why not move the tools together with the rest? I know, it's open source, lack of maintainers, but I wouldn't dare to declare my toolkit stable until basic tools work. Qt is also guilty of doing that in some ways but at least the previous version is still production ready and they move really fast.

I don't know I'll ever get over my irrational anger about how they handle(d) GTK.

[badsectoracula]

> if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen

That is certainly not a solution, you just postpone the problem.

The real solution would be the Gtk4 to be 100% backwards compatible at both the API and ABI level with Gtk3 and similarly with Gtk5, Gtk6, etc.

Otherwise you're just subscribing to wasting your time - it might be now or it might be 5 years from now, it doesn't matter however as it will happen unless the Gtk developers finally decide to stop breaking their library every few years.

(of course don't get me wrong, it is their library and they can do whatever they please with it, they are giving it for free and they are not beholden to anyone - however that doesn't mean others like to have their code broken and waste time that they could use to improve their applications instead)

[mumblemumble]

Alternatively GTK3 could get a higher level of ongoing support. That was what I was alluding to when I referenced Microsoft. For example, WinForms has technically been superseded for ages now, but, while it's not necessarily getting any big new features, WinForms apps still look decent on newer versions of Windows, benefit from things like updates to the common dialog boxes, and continue to be well-supported in new versions of the developer tools. So one doesn't necessarily have to have a lot of anxiety about leaving an old WinForms app on WinForms. With GTK3, on the other hand, I would guess that it's going to get the absolute bare minimum of love, and probably become a liability rather sooner than I might like, because the project simply doesn't have the resources to maintain a higher level of support.

And yeah, you're right, the GTK team isn't beholden to anyone. But... GUI code is expensive to write and expensive to maintain. So a GUI toolkit can have an outsize impact on the health of projects that use it. There's value in talking about things like this publicly, so that anyone who's shopping for a GUI toolkit can have a better understanding of what they might be getting into.

[badsectoracula]

Ideally they could have done that with Gtk2 which would continue on to Gtk3 and Gtk4 without breaking backwards compatibility.

Of course yes, the next best thing wrt. backwards compatibility is at least not breaking what works - but IMO that is a waste of time for both the Gtk developers (sure, it'd be self inflicted, but still) who would need to support two (or three or four or however many times they decide to break their own APIs) libraries that do essentially the same thing in different ways, and for the developers who at the end of the day will most likely need to move on to the next version at some point to gain access to new features that they may need - so they'll spend that porting time anyway.

> And yeah, you're right, the GTK team isn't beholden to anyone. But... GUI code is expensive to write and expensive to maintain. So a GUI toolkit can have an outsize impact on the health of projects that use it. There's value in talking about things like this publicly, so that anyone who's shopping for a GUI toolkit can have a better understanding of what they might be getting into.

Indeed and this is why i mention my issues with backwards compatibility whenever i see it being relevant.

I do believe the Gtk developers are free to do whatever they want as they are not beholden to my -or anyone else's- wishes for stability, especially when they give out such an otherwise high quality library for free. However that is from their perspective.

From the library users' (that is the developers who use the library) perspective however there are additional issues, like all the time you spent learning the library (breaking the API invalidates your own knowledge which is something that is also important - unless you plan to somehow live forever it makes sense to want to avoid this sort of "knowledge churn" :-P) and writing the code that uses it (important especially for framework-style libraries like Gtk that put their tendrils everywhere in your application). And even if someone believes (wrongly, IMO) that commercial developers can afford all that time, it still is an issue with FLOSS since the vast majority of which is developed during its developers' free time: that time would have better been used to improve the applications instead of keeping up with their dependencies' breakage (e.g. XFCE or... Gimp :-P).

And of course from the end users' perspective it also means that even if the developers decide to drop a program, they can keep using it for a long time without having to worry about the libraries their program depends on getting stale (since they are linked dynamically), not supporting new features (like, e.g. Wayland - AFAIK Gtk2 apps do not support it natively and chances are if a new display server is made Gtk3 apps wont support it either) or having unfixable security issues (for the applications where that makes sense at least).

But yeah, Gtk developers - or any library developers - do not need to care about all of that nor they have to really. As you wrote, it is the developers who decide or not to use a library that care about such things mostly.

Sadly at last on Linux there aren't that many choices: of the "mainstream" toolkits only Gtk and Qt exist. Gtk is, well, Gtk and Qt cannot provide "perfect" ABI compatibility even if they wanted to because of C++ (there are some hacks that could be made but i am not aware of any project doing such a thing - i think only Haiku does something similar with proxy libraries that forward the GCC C++ 2.95 calls to modern GCC C++ calls for BeOS compatibility). But Qt is also a different beast, they are a middleware company with different priorities, the people that pay money on it (and thus affect these priorities) do not care much about providing a stable platform and can affort to waste time on upgrades. From other toolkits there is also Motif but that fell out of favor and got opensourced way too late to make much of a difference - its API/ABI is stable though and has been stable for decades, but that means nothing when barely anyone uses it or develops for it.

Personally i use Lazarus and LCL. LCL uses a variety of backends, kinda like wxWidgets, but unlike wxWidgets it doesn't break its API. This pushes the issue of keeping up to date to the LCL developers (who could have spent their time in fixing LCL's other issues - of which are many - instead) but that is how things are.

I think Java and SWT might be another stable solution for a native UI, AFAIK this never broke backwards compatibility either... or at least it never did back when i looked into it several years ago. Looking at some examples in their site, several of them seem to be somewhat old so it probably is stable (isn't it great how when you do not break your API left and right you get to also get time to build better documentation that you don't have to invalidate it after a while?)

[jcelerier]

> Qt cannot provide "perfect" ABI compatibility even if they wanted to because of C++

That does not really matter in practice though. I ship a Qt app as AppImage, it works fine from CentOS 7 to the very latest ArchLinux. I just ship libc++ along with it - which is the same that I have to do in Windows anyways.

[badsectoracula]

Of course it matters in practice since we're talking about dynamic linking that applications can link against the OS-provided libraries so that they can keep gaining new features and bug fixes.

A trivial example on Windows would be how Win32 applications get to use the Win+; emoji popup even if they were made before Windows even got that feature, or how even classic VB applications can be made to run in HiDPI mode by ticking a shortcut checkbox despite being written decades before HiDPI was even a thing (assuming they use twip instead of pixel coordinates at least).

Or on Linux, how some old games made for it need their bundled SDL removed so that the games can use the system-provided version because the old version tried to use OSS or whatever was common at the time the game as written and the new version can use ALSA or even Pulse that didn't even exist in older times. And i remember reading on twitter about some distros planning to provide the SDL1-to-SDL2 wrapper as an option instead of the real SDL1 because it provides better compatibility with some modern window managers... and Wayland (that SDL1 doesn't support at all but the API doesn't really make a difference and could work perfectly fine with Wayland).

> which is the same that I have to do in Windows anyways.

Windows comes with WAY more functionality out of the box so that applications do not have to rely as much in their own libraries and can rely on the OS to provide and keep functionality up to date. Of course applications can ignore that, but they just do not get those new features and fixes.

The recent Visual C++ runtimes not being part of Windows is a baffling and really stupid decision though. I am certain it has more to do with internal politics and feuds between WinDiv and DevDiv than something practical.

[jcelerier]

> A trivial example on Windows would be how Win32 applications get to use the Win+; emoji popup even if they were made before Windows even got that feature, or how even classic VB applications can be made to run in HiDPI mode by ticking a shortcut checkbox despite being written decades before HiDPI was even a thing (assuming they use twip instead of pixel coordinates at least).

eh, I really really disagree with this. In my experience more often than not this kind of changes breaks the app in various ways. What if the app was using that shortcut for something else ? Now it's broken and can't be used anymore. Likewise for the hidpi thing that windows does, it's terrible - running the app at original resolution and applying a 2x nearest neighbor filter to the whole window would be better than that mess of "crisp" text with upscaled pixmaps that were never made for this resolution.

> Or on Linux, how some old games made for it need their bundled SDL removed so that the games can use the system-provided version because the old version tried to use OSS or whatever was common at the time the game as written and the new version can use ALSA or even Pulse that didn't even exist in older times. And i remember reading on twitter about some distros planning to provide the SDL1-to-SDL2 wrapper as an option instead of the real SDL1 because it provides better compatibility with some modern window managers... and Wayland (that SDL1 doesn't support at all but the API doesn't really make a difference and could work perfectly fine with Wayland).

I strongly believe that for old games / software it's better to use a VM / emulator for hardware of that game's era.