7 ms·

Applications written using the original Win32 API are binary and source compatible with the current version of the API. Why does GTK keep breaking backward comp

Applications written using the original Win32 API are binary and source compatible with the current version of the API. Why does GTK keep breaking backward compatibility? I understand breaking backwards compatibility a first time, maybe out of a failure to plan ahead, but not multiple times. It would be easy enough to add new subroutines to add more functionality. Is there a reason to change or remove old subroutines of which I’m not aware? Otherwise this is just causing extra work for application developers for no good reason and in many cases killing old stable applications which are no longer developed.

cycloptic 6y ago
They break backwards compatibility because there's not really much reason for them not to. The new releases have a lot of refactoring and redesigns that would break things anyway. The old ways are considered deprecated and keeping them around forever complicates the code and has about the same cost as backporting things to an old version. If it's too much work for application developers, the can keep on an old version of the library or maintain a shim. (There are still a lot of GTK2 applications out there, although distros seem to be removing them because nobody is interested in maintaining a shim or backporting things)
- rwmj 6y ago
  It's a big pain in the neck. This is the nonsense we have to go through to keep virt-p2v working on various old Linux systems (required in itself because those old systems support various obsolete/closed source hardware): https://github.com/libguestfs/virt-p2v/blob/master/gui-gtk2-compat.h https://github.com/libguestfs/virt-p2v/blob/master/gui-gtk2-... https://github.com/libguestfs/virt-p2v/blob/master/gui-gtk3-compat.h https://github.com/libguestfs/virt-p2v/blob/master/gui-gtk3-... And that's just one very small and limited application.
  - cycloptic 6y ago
    I guess I'm confused. The first one looks like backporting of newer functions to get it to work on older GTK versions. The second one looks like shims to work around not wanting to link against deprecated symbols. What could upstream possibly do there? In both cases, the issue seems to be the configuration of the target machine.
    - rwmj 6y ago
      We have to make it compile on RHEL 5 and RHEL 6¹ because some obscure SCSI drivers only work on those platforms, and you need those if you're going to virtualize the hardware (P2V). You can't just use modern Gtk on those platforms partly because it doesn't compile and partly because carrying the whole "G stack²" on those distros for a 3 dialog wizard would be a nightmare. ¹ 2007 and 2010 respectively, not sure off the top of my head what versions of Gtk those have, but old. ² It's not just Gtk, but glib and dozens of other libraries.
      - cycloptic 6y ago
        Right, so how are any upstream changes in GTK3/4 going to help with keeping the application running on GTK 2.10? I don't know what else you could there besides ship a shim.
      - pas 6y ago
        At that point ... why not drop RHEL5/6 support? Or, if p2v works on them already, why can't you have a rhel-5/6 branch and only touch it if somebody gives you a pot of 24 Karat gold?
badsectoracula 6y ago
Because the GTK developers do not care about backwards compatibility. There isn't really any other reason, as you wrote the Win32 API is backwards compatible as are the X11 libraries and a few other toolkits - perhaps the most stable is Motif, which goes back to the early 90s. Of course they do not have to care about backwards compatibility since GTK is just a library that happens to be popular enough to be widely available but not really part of any platform. The OS itself (Linux) is binary compatible going back decades. It is a bit frustrating though, but really if you want a stable GUI API either write against pure xlib or use something like Motif which even though it barely gets any updates probably wont go away any time soon as it is used in several long standing scientific and enterprise applications (ie. the unsexy stuff you rarely hear about but still work behind the scenes). It might be interesting to see what it'd take to make Motif a bit more themeable though.
- cycloptic 6y ago
  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).
foolmeonce 6y ago
The lifecycle is at its worst at this very moment and is about 10 years (the last moment you could have made a GTK 2 app before 3 released). The price of backwards compatibility is keeping backward design. Microsoft stated a few times that they couldn't keep the exact interfaces of Win32 without leaving security problems inherent in the mis-design of original interfaces. I have no idea if they intentionally broke the interfaces, but Wine is sometimes more compatible with old win32 than windows.
- badsectoracula 6y ago
  In my experience Wine is more compatible when it comes to older games (especially those abusing the APIs), but when it comes to older (and newer) GUI applications it has a lot of issues. And for older games there are often alternatives in Windows (e.g. dgVoodoo2 which reimplements older DirectX and Glide versions under Direct3D 11 and i think nowadays 12) that provide even better compatibility and features.
enriquto 6y ago
> Why does GTK keep breaking backward compatibility? Binary compatibility is mostly irrelevant, any sane distribution scheme is based on static binaries. Now, breaking source backwards compatibility is a real tragedy.
xorcist 6y ago
Maybe it was a mistake to keep using the GTK name. The overhaul between major versions, at least between 2 and 3, was large enough to warrant a new name. Microsoft has introduced just as many new toolkits during the same time, but nobody expects WinForms to be backwards compatible with MFC. That would have given application developers a better chance to keep maintaining the toolkit long after GTK developers lost interest.
- CyberRabbi 6y ago
  Okay so if each GTK version exposes a fundamentally different toolkit framework (similar to the differences between win32/mfc/winforms/uwp) why do they expect application developers to “upgrade”? These should be lateral changes as you suggest and upgrading would be meaningless. Just like it’s meaningless to “upgrade” an MFC app to a winforms app.
  - pas 6y ago
    They don't expect. But usually some Gnome devs are GTK devs, so usually the whole things happens for a reason, and that reason is to have better APIs to be able to write better desktop applications. GTK3 became "final" in 2016 with 3.22. That was when GTK4 development started. And many applications just started to be ported to 3. Then 3.24 as a maintenance release came out in 2018. And in almost exactly 4 years 4.0 is ready for general availability, but it's likely far from "final" and stable. So GTK3 continues to be maintained for a good while. (Though GTK2 is now EOL.)
jpobst 6y ago
Indeed. One of the main reasons we abandoned Pinta (https://github.com/PintaProject/Pinta https://github.com/PintaProject/Pinta) is we had to rewrite a significant portion of the app if we wanted to move to GTK3, as we had many custom UI needs. See also: GIMP, still on GTK2. Inkscape released on GTK3 just within the past year or 2
- aljarry 6y ago
  For Gimp there's a first beta with GTK3.
floatboth 6y ago
GTK is not like Win32. Think GTK2 ~= WinForms, GTK3 ~= WPF, GTK4 ~= UWP. The "versions" are parallel installable, you don't have to migrate every app to the newest toolkit ASAP. But unlike with Windows, old versions do get phased out and abandoned, because there's no super-rich corporate force sponsoring their perpetual maintenance.
- CyberRabbi 6y ago
  If GTK is operating in a situation where there is no “rich corporate force” to sponsor the maintenance of old versions then it is a strategic error for them to break backwards compatibility. At this point I cannot imagine a sane third party application developer choosing to build on top of GTK. The clock starts ticking on the life of your application the moment you choose GTK.
  - cycloptic 6y ago
    The alternative would be never refactoring anything and allowing technical debt and complexity to balloon out of control, which would also be a strategic error for a small project without many resources. The ticking clock you're referring to is real, but it applies to any open source library you're depending on that you aren't contributing anything to, not just GTK. It can't be avoided just by switching to another open source toolkit. If it really bothers you, start contributing and help out!
    - tinus_hn 6y ago
      It’s not like Google starting a new framework and abandoning another every six months. GTK2 was released in 2002 and is still under maintenance.
    - hda2 6y ago
      Contributing to each dependency you use is not realistic. What instead happens is that people leave GTK for more stable dependencies. This is what I did. That's what many likely choose to do.
madhadron 6y ago
This is why I've pretty well decided that Swing on the JVM is the way to go. I have some confidence that a jar I compile today for a Swing app is going to work in ten years.
- rdsubhas 6y ago
  That's really weird to hear. If you build an app with GTK3 today, it's still going to work for 10 years. It's compiled into the application, it's not a runtime API. Even if you upgrade GNOME to some futuristic 10 year version, the GTK3 compiled app will just continue to work fine. The parent thread is comparing a runtime API (Win32) with a compile-time library (GTK).
  - seba_dos1 6y ago
    As a case in point, I just played with an unmodified GTK2 mapping app (FoxtrotGPS) from Openmoko times (2008) on my Librem 5 phone running modern Wayland shell (phosh). Wasn't crisp because GTK2 doesn't support hidpi, and touch support could be better, but worked very well otherwise.
  - madhadron 6y ago
    If I build a static binary for each platform I want to release it on and we don't have another a.out to elf transition... Oh, and building it will end up needing a special environment as opposed to the stock JDK.
- MaxBarraclough 6y ago
  Why would you use Swing over JavaFX, for new projects?
  - madhadron 6y ago
    Swing is part of the core JDK and fully mature.
    - MaxBarraclough 6y ago
rdsubhas 6y ago
You are comparing a runtime API (Win32/Xorg) with a compile-time library (GTK). They are totally different. It's totally fine for a library to have new versions, and for those new versions to be breaking. You can run two applications with GTK3 and GTK4, and maybe 10 years into the future GTK10 in parallel. They will just look different, but nothing else will change. It's not as if the old application built with GTK3 will crash or not start. But if you break the Win32 API, a whole lot of desktop applications will crash.
- CyberRabbi 6y ago
  If GTK were simply a so-called compile-time library, they wouldn’t encourage people to port their applications to the newest version. Applications are not expected to vendor private versions of GTK with their source distributions.
  - seba_dos1 6y ago
    It is though. Otherwise you wouldn't be able to run The GIMP on current platforms, as its stable release is still on GTK2. Porting is encouraged because GTK2 isn't maintained anymore and lacks features expected in 2020, like hidpi support.
    - CyberRabbi 6y ago
      Do you realize that it’s far easier for an application like GIMP to add hidpi support to gtk2 than port to GTK3/4? If that’s the case then you have failed as a library developer.
      - seba_dos1 6y ago
        Nonsense. Make a thought experiment and imagine that each new major GTK (or Qt) version had a different name. You'd still have old GTK, which wouldn't be maintained anymore as the devs moved on, and new NTK or whatever, which would be what was still developed and used these days. Somewhat similar to old GTK since that was its roots, yet distinct. And that's exactly what happens, they just reuse the name because well, why wouldn't they. You can still use GTK2 just like you can use Win32 API, but nobody does modern apps in either GTK2 or Win32 API or expects them to smoothly blend into modern desktop these days. Not even speaking about the fact that The GIMP is a very special case that makes it probably the hardest GTK app to port to newer versions in existence.
CyberDildonics 6y ago
What do you mean by subroutines?
zaro 6y ago
Actually if you read the links in the 'What's new' section, most of them start with the reason why they needed to break the backward fucntionality for this feature.
benibela 6y ago
Yeah, I used to write my programs with Delphi My 20 year old projects run perfectly on Linux with WINE Now there is Lazarus to port Delphi code to a native Linux version, but it is using GTK2 and that is running much worse. (or through qt4 but that is even worse) The good thing is, if Lazarus gets a GTK3/4 update, my old code is supposed to run on the new GTK unchanged. The bad thing is, Lazarus is not popular so hardly anyone is working on those updates.

cycloptic 6y ago

They break backwards compatibility because there's not really much reason for them not to. The new releases have a lot of refactoring and redesigns that would break things anyway. The old ways are considered deprecated and keeping them around forever complicates the code and has about the same cost as backporting things to an old version. If it's too much work for application developers, the can keep on an old version of the library or maintain a shim. (There are still a lot of GTK2 applications out there, although distros seem to be removing them because nobody is interested in maintaining a shim or backporting things)

rwmj 6y ago
It's a big pain in the neck. This is the nonsense we have to go through to keep virt-p2v working on various old Linux systems (required in itself because those old systems support various obsolete/closed source hardware): https://github.com/libguestfs/virt-p2v/blob/master/gui-gtk2-compat.h https://github.com/libguestfs/virt-p2v/blob/master/gui-gtk2-... https://github.com/libguestfs/virt-p2v/blob/master/gui-gtk3-compat.h https://github.com/libguestfs/virt-p2v/blob/master/gui-gtk3-... And that's just one very small and limited application.
- cycloptic 6y ago
  I guess I'm confused. The first one looks like backporting of newer functions to get it to work on older GTK versions. The second one looks like shims to work around not wanting to link against deprecated symbols. What could upstream possibly do there? In both cases, the issue seems to be the configuration of the target machine.
  - rwmj 6y ago
    We have to make it compile on RHEL 5 and RHEL 6¹ because some obscure SCSI drivers only work on those platforms, and you need those if you're going to virtualize the hardware (P2V). You can't just use modern Gtk on those platforms partly because it doesn't compile and partly because carrying the whole "G stack²" on those distros for a 3 dialog wizard would be a nightmare. ¹ 2007 and 2010 respectively, not sure off the top of my head what versions of Gtk those have, but old. ² It's not just Gtk, but glib and dozens of other libraries.
    - cycloptic 6y ago
      Right, so how are any upstream changes in GTK3/4 going to help with keeping the application running on GTK 2.10? I don't know what else you could there besides ship a shim.
    - pas 6y ago
      At that point ... why not drop RHEL5/6 support? Or, if p2v works on them already, why can't you have a rhel-5/6 branch and only touch it if somebody gives you a pot of 24 Karat gold?

badsectoracula 6y ago

Because the GTK developers do not care about backwards compatibility. There isn't really any other reason, as you wrote the Win32 API is backwards compatible as are the X11 libraries and a few other toolkits - perhaps the most stable is Motif, which goes back to the early 90s. Of course they do not have to care about backwards compatibility since GTK is just a library that happens to be popular enough to be widely available but not really part of any platform. The OS itself (Linux) is binary compatible going back decades. It is a bit frustrating though, but really if you want a stable GUI API either write against pure xlib or use something like Motif which even though it barely gets any updates probably wont go away any time soon as it is used in several long standing scientific and enterprise applications (ie. the unsexy stuff you rarely hear about but still work behind the scenes). It might be interesting to see what it'd take to make Motif a bit more themeable though.

cycloptic 6y ago
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).

foolmeonce 6y ago

The lifecycle is at its worst at this very moment and is about 10 years (the last moment you could have made a GTK 2 app before 3 released). The price of backwards compatibility is keeping backward design. Microsoft stated a few times that they couldn't keep the exact interfaces of Win32 without leaving security problems inherent in the mis-design of original interfaces. I have no idea if they intentionally broke the interfaces, but Wine is sometimes more compatible with old win32 than windows.

badsectoracula 6y ago
In my experience Wine is more compatible when it comes to older games (especially those abusing the APIs), but when it comes to older (and newer) GUI applications it has a lot of issues. And for older games there are often alternatives in Windows (e.g. dgVoodoo2 which reimplements older DirectX and Glide versions under Direct3D 11 and i think nowadays 12) that provide even better compatibility and features.

enriquto 6y ago

> Why does GTK keep breaking backward compatibility? Binary compatibility is mostly irrelevant, any sane distribution scheme is based on static binaries. Now, breaking source backwards compatibility is a real tragedy.

xorcist 6y ago

Maybe it was a mistake to keep using the GTK name. The overhaul between major versions, at least between 2 and 3, was large enough to warrant a new name. Microsoft has introduced just as many new toolkits during the same time, but nobody expects WinForms to be backwards compatible with MFC. That would have given application developers a better chance to keep maintaining the toolkit long after GTK developers lost interest.

CyberRabbi 6y ago
Okay so if each GTK version exposes a fundamentally different toolkit framework (similar to the differences between win32/mfc/winforms/uwp) why do they expect application developers to “upgrade”? These should be lateral changes as you suggest and upgrading would be meaningless. Just like it’s meaningless to “upgrade” an MFC app to a winforms app.
- pas 6y ago
  They don't expect. But usually some Gnome devs are GTK devs, so usually the whole things happens for a reason, and that reason is to have better APIs to be able to write better desktop applications. GTK3 became "final" in 2016 with 3.22. That was when GTK4 development started. And many applications just started to be ported to 3. Then 3.24 as a maintenance release came out in 2018. And in almost exactly 4 years 4.0 is ready for general availability, but it's likely far from "final" and stable. So GTK3 continues to be maintained for a good while. (Though GTK2 is now EOL.)

jpobst 6y ago

Indeed. One of the main reasons we abandoned Pinta (https://github.com/PintaProject/Pinta https://github.com/PintaProject/Pinta) is we had to rewrite a significant portion of the app if we wanted to move to GTK3, as we had many custom UI needs. See also: GIMP, still on GTK2. Inkscape released on GTK3 just within the past year or 2

aljarry 6y ago
For Gimp there's a first beta with GTK3.

floatboth 6y ago

GTK is not like Win32. Think GTK2 ~= WinForms, GTK3 ~= WPF, GTK4 ~= UWP. The "versions" are parallel installable, you don't have to migrate every app to the newest toolkit ASAP. But unlike with Windows, old versions do get phased out and abandoned, because there's no super-rich corporate force sponsoring their perpetual maintenance.

CyberRabbi 6y ago
If GTK is operating in a situation where there is no “rich corporate force” to sponsor the maintenance of old versions then it is a strategic error for them to break backwards compatibility. At this point I cannot imagine a sane third party application developer choosing to build on top of GTK. The clock starts ticking on the life of your application the moment you choose GTK.
- cycloptic 6y ago
  The alternative would be never refactoring anything and allowing technical debt and complexity to balloon out of control, which would also be a strategic error for a small project without many resources. The ticking clock you're referring to is real, but it applies to any open source library you're depending on that you aren't contributing anything to, not just GTK. It can't be avoided just by switching to another open source toolkit. If it really bothers you, start contributing and help out!
  - tinus_hn 6y ago
    It’s not like Google starting a new framework and abandoning another every six months. GTK2 was released in 2002 and is still under maintenance.
  - hda2 6y ago
    Contributing to each dependency you use is not realistic. What instead happens is that people leave GTK for more stable dependencies. This is what I did. That's what many likely choose to do.

madhadron 6y ago

This is why I've pretty well decided that Swing on the JVM is the way to go. I have some confidence that a jar I compile today for a Swing app is going to work in ten years.

rdsubhas 6y ago
That's really weird to hear. If you build an app with GTK3 today, it's still going to work for 10 years. It's compiled into the application, it's not a runtime API. Even if you upgrade GNOME to some futuristic 10 year version, the GTK3 compiled app will just continue to work fine. The parent thread is comparing a runtime API (Win32) with a compile-time library (GTK).
- seba_dos1 6y ago
  As a case in point, I just played with an unmodified GTK2 mapping app (FoxtrotGPS) from Openmoko times (2008) on my Librem 5 phone running modern Wayland shell (phosh). Wasn't crisp because GTK2 doesn't support hidpi, and touch support could be better, but worked very well otherwise.
- madhadron 6y ago
  If I build a static binary for each platform I want to release it on and we don't have another a.out to elf transition... Oh, and building it will end up needing a special environment as opposed to the stock JDK.
MaxBarraclough 6y ago
Why would you use Swing over JavaFX, for new projects?
- madhadron 6y ago
  Swing is part of the core JDK and fully mature.
  - MaxBarraclough 6y ago

rdsubhas 6y ago

You are comparing a runtime API (Win32/Xorg) with a compile-time library (GTK). They are totally different. It's totally fine for a library to have new versions, and for those new versions to be breaking. You can run two applications with GTK3 and GTK4, and maybe 10 years into the future GTK10 in parallel. They will just look different, but nothing else will change. It's not as if the old application built with GTK3 will crash or not start. But if you break the Win32 API, a whole lot of desktop applications will crash.

CyberRabbi 6y ago
If GTK were simply a so-called compile-time library, they wouldn’t encourage people to port their applications to the newest version. Applications are not expected to vendor private versions of GTK with their source distributions.
- seba_dos1 6y ago
  It is though. Otherwise you wouldn't be able to run The GIMP on current platforms, as its stable release is still on GTK2. Porting is encouraged because GTK2 isn't maintained anymore and lacks features expected in 2020, like hidpi support.
  - CyberRabbi 6y ago
    Do you realize that it’s far easier for an application like GIMP to add hidpi support to gtk2 than port to GTK3/4? If that’s the case then you have failed as a library developer.
    - seba_dos1 6y ago
      Nonsense. Make a thought experiment and imagine that each new major GTK (or Qt) version had a different name. You'd still have old GTK, which wouldn't be maintained anymore as the devs moved on, and new NTK or whatever, which would be what was still developed and used these days. Somewhat similar to old GTK since that was its roots, yet distinct. And that's exactly what happens, they just reuse the name because well, why wouldn't they. You can still use GTK2 just like you can use Win32 API, but nobody does modern apps in either GTK2 or Win32 API or expects them to smoothly blend into modern desktop these days. Not even speaking about the fact that The GIMP is a very special case that makes it probably the hardest GTK app to port to newer versions in existence.

CyberDildonics 6y ago

What do you mean by subroutines?

zaro 6y ago

Actually if you read the links in the 'What's new' section, most of them start with the reason why they needed to break the backward fucntionality for this feature.

benibela 6y ago

Yeah, I used to write my programs with Delphi My 20 year old projects run perfectly on Linux with WINE Now there is Lazarus to port Delphi code to a native Linux version, but it is using GTK2 and that is running much worse. (or through qt4 but that is even worse) The good thing is, if Lazarus gets a GTK3/4 update, my old code is supposed to run on the new GTK unchanged. The bad thing is, Lazarus is not popular so hardly anyone is working on those updates.