Jumping to pure Xlib or Motif is a bit beside the point, to that end you might as well use GTK1 or GTK2 if you don't mind using an old stable API that is not really being updated anymore.
That sort of "backwards compatibility" is useless in the long run and a big source of waste of time for the developers who rely on their library - see XFCE or even Gimp as examples of projects wasting tons of time just to do the same stuff just with a different API.
In addition it isn't what the thread is about which should have been obvious from the Win32 as an example. When you use Win32 you get the latest fixes and features even in applications that haven't been updated for two decades - for example you get new common dialogs and access to shell extensions (e.g. TortoiseSvn/Git integration) that didn't exist back when those applications were made.
Backwards compatibility isn't just about keeping the old stuff running as they were back when they were released - that is just the absolute minimum. It is also about adding new features and fixing bugs that all applications - both old and new - can benefit whenever possible.
> Jumping to pure Xlib or Motif is a bit beside the point, to that end you might as well use GTK1 or GTK2 if you don't mind using an old stable API that is not really being updated anymore.
Xlib and Motif are not equivalent to GTK1 and GTK2 since they do receive updates and bugfixes, even if they rarely receive new features (though both do receive new features too).
I get what you're saying, but asking "why doesn't my old API get new features" is a different thing than asking for backwards compatibility because that entails actually modifying the old applications to support new API features, not just maintaining compatibility with them. If someone really wants to step up and backport features to GTK2, that's always possible, you don't need to wait for the GTK4 developers to figure it out.
If what you're looking for is a way to roll out some new widgets one by one and transition to a new version slowly, I agree that's something that could be worked on. But it requires a bunch of additional work that's mostly orthogonal to just shipping a new toolkit and it may not make sense for it to happen upstream.
If GTK3's API was backwards compatible (both in binary and source form) with GTK2's API then the developers of all the applications that relied on GTK2 wouldn't have to spend any time changing their applications to work with GTK3 nor make any "weighting" between doing these changes or staying on a library that wont receive any further updates and features after a while. And in practice this isn't really much of a choice unless the GTK developers also committed to updating, fixing and improving (ie. adding new features) to the previous library - at which point why bother with the new version at all?
This is a waste of time because the developers of those applications could have spend their (often limited, since they're not paid to make those applications and instead make them in their free time) development time on fixing bugs and adding features to these applications that directly benefit the end users instead of trying to catch up with whatever stuff GTK3 broke (and now will be broken again in GTK4).
> I get what you're saying, but asking "why doesn't my old API get new features" is a different thing than asking for backwards compatibility because that entails actually modifying the old applications to support new API features, not just maintaining compatibility with them.
No, this is exactly backwards compatibility in the best way: the old applications get new features without even having to recompile them. This is how it works, e.g. in Win32 where as i wrote above you get new features in applications that were compiled 20+ years ago.
You only need to modify existing applications so that they can use new features when it makes sense for those new features to be requested by the application. But, for example, you do not need to modify existing GTK2 applications to add Wayland support in GTK2, or to improve the a common dialog like the file picker, or to add an emoji picker in text editing areas (which, btw, is also a feature that Windows applications got in Windows 10 which works even in applications compiled many years ago before emoji was a thing outside Japan), or a bunch of other stuff.
What you describe would only be an issue if someone statically linked against GTK but the overwhelmingly vast majority of applications link against GTK dynamically and on Linux they all pretty much use the distribution's libraries instead of bundling their own.
> If someone really wants to step up and backport features to GTK2, that's always possible, you don't need to wait for the GTK4 developers to figure it out.
Yes, of course anyone could improve GTK1, GTK2, etc but what is being discussed here isn't if it is technically possible to improve these libraries without breaking backwards compatibility (it obviously is) but about what the (official) developers of these libraries are actually doing with regards to backwards compatibility.
If someone really wants to backport things like wayland support or emojis to GTK2, or make a shim layer to support all the old GTK2 APIs in GTK3, you could probably get people on board to take those patches somewhere. I know adding wayland support would not be simple and would probably break things as there are a lot of things in GDK2 that were direct mappings onto X11 APIs that have no analog in wayland. As the backports pile up you would have to weigh the cost of doing that versus just porting the application and getting the additional benefits of porting to a newer version. It would only be a total waste of time if there were no benefits to porting, but this is not the case.
I just doubt any of the GTK4 developers are going to want to drop what they're working on now to do these things given the risk it carries combined with the fact that there are workarounds for these missing features.
As i wrote a few messages above, that is the absolute minimum to call "backwards compatibility" so i'm not sure why you need to be clear since we agree on that part
> Adding new features is often at odds with this because it can break things in subtle ways.
You take that into consideration when you decide to add new features, it isn't like features come as demands from the gods in what and how to implement. And if you break things in subtle ways, you can fix them down the road if that is a problem - it isn't like broken code has to remain broken.
> You might be able to make some small backend changes, bringing back some of the major breaking changes to widgets or to the rendering model is out of the question.
The idea is to not make breaking changes to widgets in the first place. And changing the rendering model should also happen in a way that doesn't break the existing code (e.g. add a compatibility layer for custom widgets that use the previous rendering model and either make any customized widgets -e.g. buttons- to detect that they are customized and use the older rendering model in that case so they remain compatible but the new rendering model for newer code or create new widgets that use the new rendering model with an API that is as drop-in as possible so that 99% of the changes can be a search and replace in codebases).
Yes, that makes things harder than simply ignoring backwards compatibility and expecting every single application that uses your library to change their own code and break any applications that cannot update to the new APIs/ABIs, but that is the price for doing backwards compatibility properly.
Of course that is too late now for GTK and as i wrote previously (and later), the developers do not care about backwards compatibility anyway so i do not expect them to do anything about that when GTK5 comes around and instead they'd just expect everyone to waste time changing their working GTK4 code to use GTK5.
> If someone really wants to backport things like wayland support or emojis to GTK2, or [...] this is not the case.
You are missing the point, my message wasn't about what could or not be done by 3rd parties to improve GTK2 or whatever, but about what GTK developers themselves decided to do. What someone else would do is absolutely irrelevant to the topic.
> I just doubt any of the GTK4 developers are going to want to drop what they're working on now to do these things given the risk it carries combined with the fact that there are workarounds for these missing features.
I do not expect that to happen either, after all my first message in this submission even began with "Because the GTK developers do not care about backwards compatibility."
The GTK developers are just ordinary people like you or I who volunteered to work on it, if you want to change this situation then you or someone else can step up and become a GTK developer and work on this. Then you can say they care about it :) I think it is incorrect to say they don't care about backwards compatibility anyway, you seem to agree that they would meet that minimum required to claim backwards compatibility.
The GTk developers aren’t ordinary people. They comprise an organization of trusted individuals and leaders. Not to mention, Many of them are employees are large companies like Red Hat and Canonical. They have resources. The likelihood of a random strangers contributions being upstreamed are low, let alone them setting project direction around backwards compatibility.
Hundreds if not thousands of apps have been left behind in GTK2 and GTK1 before that. Those are all apps that could be part of the current GNOME ecosystem, now they will look like bad foreign apps. Tens of thousands of man hours completely wasted.
This will kill the GNOME desktop. It’s a dead end for anyone but GNOME developers. Everyone sees it. GTK4 is just the latest demonstration of their incompetence and disregard for other developers.
Please don't use this type of hyperbole, I've heard this type of thing often in various contexts, and while it may be fun to say, it's inaccurate and it's thoroughly unproductive in getting the actual issues solved. What you view as incompetence and disregard is more accurately described as "lack of time." IIRC there are only really 2-3 people working full time on GTK, and most of their efforts are focused on getting new releases out the door. It's not as many resources as it may seem from the outside and they don't have time to do everything that people want. They depend on volunteer contributors to handle the long tail of issues and edge cases that come up with older applications.
If you'd like to improve GTK2 and GTK1 applications, please find a way to contribute and help out! I can help to point you in a direction if you want. (I don't think it's really much of a big deal if older applications look weird, the main concern with them is usually that they don't break. From this angle, GTK1 and GTK2 apps are not being left behind, they work perfectly fine even on a modern system) I'll warn you though, it's not trivial to get a legacy app to look and act native on a modern platform. If you really want to do a good job at it, you have to manually redesign each of the apps individually and it gets time-consuming.
I personally think it would be great if XFCE/Mate/Budgie/Cinnamon/etc had the resources to pay more full time developers to contribute upstream and collaborate more with the GNOME people, but we are not there yet unfortunately.
Wrong, GTK 1 was removed from Debian over 10 years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520441
Again, this isn't about what can be technically possible. As the other poster wrote, it is a criticism towards the decisions of the GTK developers. That someone else could take the code and change it, is completely, absolutely, 100% irrelevant. It has nothing to do with the comments here, they aren't about if it is technically possible to add a compatibility layer on GTK3 or GTK4 or whatever nor who will make it.
It is ALL about the GTK development team's decisions, including the decisions that make a backwards compatibility harder.
Also caring about backwards compatibility isn't something that can be bolted on top by a 3rd party, it is something the library has to keep in mind in the design phase. And it isn't something that can be thought as a separate component, it is something that has to be at the same level as everything else. Expecting that it is something that "shouldn't hold up a GTK release" is a completely wrong way of thinking about backwards compatibility - a project that cares about being backwards compatible considers it as important as any other change (new features, bug fixes, etc) and not something to be an afterthought.
> The GTK developers are just ordinary people like you or I who volunteered to work on it, if you want to change this situation then you or someone else can step up and become a GTK developer and work on this. Then you can say they care about it :)
Sure, they may be (i do not know) and they have all the rights to ignore backwards compatibility - it isn't like i'm paying them to work on their library or be in a position to make any demands out of them. But that doesn't mean i wont say they do not care about backwards compatibility.
> I think it is incorrect to say they don't care about backwards compatibility anyway,
It is absolutely correct because this is what they have repeatedly shown.
> you seem to agree that they would meet that minimum required to claim backwards compatibility.
No, i do agree with that, what i agreed with is the definition that keeping code running is the absolute minimum one would do to provide backwards compatibility, but i never claimed that the GTK developers care about it. These are two different things: one can not care about backwards compatibility, yet still provide that minimum amount for it for practical and strategic reasons to entice people move to the next version.
>Expecting that it is something that "shouldn't hold up a GTK release" is a completely wrong way of thinking about backwards compatibility
Why? Once you decide to refactor an API you have to maintain an extra piece to translate the old to the new, there is no way around that. Developers can spend time before the release working on this translation piece alongside the new features or they can just release it now so people can test the new API before deciding to invest in developing that. For an open source project I can't see how the first option really makes sense, and if your argument is that they should have been developing it the whole time, that is essentially what they were doing for the entirety of the GTK3 development cycle.
That is being generous in assuming that it's even possible to do this, sometimes a design is so flawed that you can't even make it work at all with the new stuff. At some point you have decide to cut deprecated APIs or you are left with an infinitely growing pile of technical debt. I referred to this elsewhere, but old GTK1/2 applications that use raw unscaled pixel buffers are an example: there is no backwards compatibility that is going to work here that makes them function correctly with high dpi. It simply cannot work if the application is hardcoded to use an old API that has no concept of dpi or scale and assumes a pixel is always the same size. (Maybe someone can cheat with AI upscaling algorithms but those are usually pretty slow :)
I guess to put it another way: I don't see any way that GTK4 could have been designed differently to do something like make it easier to compile GTK1 apps against it while reaping all the benefits of GTK4. If somebody wants to make a GTK1 shim for GTK4 that translates GTK1 API calls into GTK4 API calls, they can go do it now, it would probably be a pain and it's probably not going to magically get you all the new benefits that would come from just porting the application to GTK4 and refactoring to use its new techniques along the way.
What you're describing is not backward compatibility, it's forward compatibility.
The OS is backward compatible with old applications that continue to run. The old applications are forward compatible with newer versions of the operating system including some of the new features that are added.
Achieving backward and forward compatibility (the combination is often called "full compatibility") is actually quite difficult. The resources Microsoft throws at this problem and the related coordination costs are massive (and conversely, the progress any individual developer sees on their particular tasks is often glacial)[0]. In the open source world, I think only web browsers typically see anything resembling a similar level of effort applied to evolving the platform while maintaining compatibility with extant (and often buggy) code, and that's still a much smaller problem (though it might not be after another decade or two), since for all intents and purposes, the web as a whole is a "rolling release" system with bugs and incompatibilities popping up and being fixed constantly.
[0] http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c...
Conversely, Microsoft is rather notorious for not making many of its own offerings forward compatible with themselves. For example, old versions of Office cannot open or edit files saved by newer versions. And while new versions of Office will open older format files, they then save the file in the new version of the format by default. This one-way ratchet "strongly encourages" upgrades in lockstep.