4 ms·

I'm not sure what you mean waste of time. If they weighed the cost of doing a port versus the cost of staying on GTK1 or GTK2 and backporting things, and they c

I'm not sure what you mean waste of time. If they weighed the cost of doing a port versus the cost of staying on GTK1 or GTK2 and backporting things, and they chose the port, it seems like according to them that would be the least time-wasting option. 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.

rwmj 6y ago
The problem is that Gtk has removed features, so old Gtk-using programs no longer even compile. If we could write a program using only old Gtk APIs and it would still work on new Gtk then it would be fine, excepting the obvious point that the programs would not be able to use newer features/widgets, but for many programs that would be a fine trade-off if it was available.
- cycloptic 6y ago
  The entire point of a new version is that it has newer features/widgets. Why even bother using a new GTK version if you didn't care about using the new features/widgets? In that case you could still compile against the old version and expect it to work as it always has. 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.
badsectoracula 6y ago
> I'm not sure what you mean waste of time. If they weighed the cost of doing a port versus the cost of staying on GTK1 or GTK2 and backporting things, and they chose the port, it seems like according to them that would be the least time-wasting option. 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.
- cycloptic 6y ago
  I'm not going to argue about semantics but I want to be clear here: the basic definition of "backwards compatibility" is keeping the old thing working. Adding new features is often at odds with this because it can break things in subtle ways. 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. 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.
  - badsectoracula 6y ago
    > I'm not going to argue about semantics but I want to be clear here: the basic definition of "backwards compatibility" is keeping the old thing working. 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."

rwmj 6y ago

The problem is that Gtk has removed features, so old Gtk-using programs no longer even compile. If we could write a program using only old Gtk APIs and it would still work on new Gtk then it would be fine, excepting the obvious point that the programs would not be able to use newer features/widgets, but for many programs that would be a fine trade-off if it was available.

cycloptic 6y ago
The entire point of a new version is that it has newer features/widgets. Why even bother using a new GTK version if you didn't care about using the new features/widgets? In that case you could still compile against the old version and expect it to work as it always has. 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.

badsectoracula 6y ago

> I'm not sure what you mean waste of time. If they weighed the cost of doing a port versus the cost of staying on GTK1 or GTK2 and backporting things, and they chose the port, it seems like according to them that would be the least time-wasting option. 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.

cycloptic 6y ago
I'm not going to argue about semantics but I want to be clear here: the basic definition of "backwards compatibility" is keeping the old thing working. Adding new features is often at odds with this because it can break things in subtle ways. 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. 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.
- badsectoracula 6y ago
  > I'm not going to argue about semantics but I want to be clear here: the basic definition of "backwards compatibility" is keeping the old thing working. 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."