7 ms·

The GTK developers do care about backwards compatibility, as evidenced by their continued maintenance of GTK3. Jumping to pure Xlib or Motif is a bit beside th

The GTK developers do care about backwards compatibility, as evidenced by their continued maintenance of GTK3. 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.

badsectoracula 6y ago
> The GTK developers do care about backwards compatibility, as evidenced by their continued maintenance of GTK3. 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).
- cycloptic 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. 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.
- webmaven 6y ago
  > 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. 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-crapfest.html http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c...
  - cycloptic 6y ago
    Thank you, I knew there was a separate phrase to describe this, but I forgot what it was.
    - webmaven 6y ago
      That's understandable, especially as the effort to make old apps forward compatible isn't being made by the application developer here, but by the platform developer. 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.
owaislone 6y ago
GTK3 broke the theming API almost every minor release.

badsectoracula 6y ago

> The GTK developers do care about backwards compatibility, as evidenced by their continued maintenance of GTK3. 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).

cycloptic 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. 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.
webmaven 6y ago
> 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. 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-crapfest.html http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c...
- cycloptic 6y ago
  Thank you, I knew there was a separate phrase to describe this, but I forgot what it was.
  - webmaven 6y ago
    That's understandable, especially as the effort to make old apps forward compatible isn't being made by the application developer here, but by the platform developer. 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.

owaislone 6y ago

GTK3 broke the theming API almost every minor release.