6 ms·

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 new

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.
    - cycloptic 6y ago
      Jumping from dependency to dependency forever hoping that someone else is always going to do the right thing is not a viable option long term, even moreso if you want to build a large application that lasts a while. Realistically, most people who decide to ditch GTK seem to switch to Qt and either start contributing there or pay for consulting/LTS/commercial licenses eventually, because that is the only comparably modern option for native widgets on Linux/BSD.
      - hda2 6y ago
        Moving from one toolkit to another is an expensive and tedious process. Speaking from experience, those who need to do it tend to do it once and they do their homework to make sure that the toolkit they choose has a sane API development process. So yes, jumping from dependency to dependency is not a viable option long term. Luckily you only need to jump away from GTK once.
        cycloptic 6y ago
        You also only need to jump away from Qt once, if that doesn't work for you for whatever reason. If the toolkit is open source, and your "homework" doesn't include looking into the contribution process and how it goes working with upstream, then I would say you are doing yourself a disservice considering how this is the most critical dependency that a GUI application has. That gets more important the more your project gets invested in the toolkit, doubly so if you aren't paying for support. (Essentially that means you're supporting it yourself or relying on flaky advice from IRC and stack overflow, all the usual caveats apply there. Ignoring upstream and refusing to talk to them or collaborate is really not going to help you in that case)
        hda2 6y ago
        Of course, but that "homework" would also include considering the incentives and goals of the authors behind the toolkit. If we took the authors of Qt as an example, their incentives and goals are clear. If they needlessly break their API, they will loose their customers and go bankrupt. These incentives have translated in one of the most smoothest major GUI toolkit transitions I've seen (Qt4 to Qt5). As far as contribution processes go, both upstreams are equally tedious to work with. I doubt GTK would be willing to accept your code contribution if you added systray icons support back to GTK4 for example. So while the contribution process does matter, it doesn't matter as much as you make it out to be.
  - CyberRabbi 6y ago
    > The alternative would be never refactoring anything and allowing technical debt and complexity to balloon out of control It’s simply false that retaining API backwards compatibility prevents refactoring and necessarily causes technical debt to balloon.

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.
  - cycloptic 6y ago
    Jumping from dependency to dependency forever hoping that someone else is always going to do the right thing is not a viable option long term, even moreso if you want to build a large application that lasts a while. Realistically, most people who decide to ditch GTK seem to switch to Qt and either start contributing there or pay for consulting/LTS/commercial licenses eventually, because that is the only comparably modern option for native widgets on Linux/BSD.
    - hda2 6y ago
      Moving from one toolkit to another is an expensive and tedious process. Speaking from experience, those who need to do it tend to do it once and they do their homework to make sure that the toolkit they choose has a sane API development process. So yes, jumping from dependency to dependency is not a viable option long term. Luckily you only need to jump away from GTK once.
      - cycloptic 6y ago
        You also only need to jump away from Qt once, if that doesn't work for you for whatever reason. If the toolkit is open source, and your "homework" doesn't include looking into the contribution process and how it goes working with upstream, then I would say you are doing yourself a disservice considering how this is the most critical dependency that a GUI application has. That gets more important the more your project gets invested in the toolkit, doubly so if you aren't paying for support. (Essentially that means you're supporting it yourself or relying on flaky advice from IRC and stack overflow, all the usual caveats apply there. Ignoring upstream and refusing to talk to them or collaborate is really not going to help you in that case)
        hda2 6y ago
        Of course, but that "homework" would also include considering the incentives and goals of the authors behind the toolkit. If we took the authors of Qt as an example, their incentives and goals are clear. If they needlessly break their API, they will loose their customers and go bankrupt. These incentives have translated in one of the most smoothest major GUI toolkit transitions I've seen (Qt4 to Qt5). As far as contribution processes go, both upstreams are equally tedious to work with. I doubt GTK would be willing to accept your code contribution if you added systray icons support back to GTK4 for example. So while the contribution process does matter, it doesn't matter as much as you make it out to be.
- CyberRabbi 6y ago
  > The alternative would be never refactoring anything and allowing technical debt and complexity to balloon out of control It’s simply false that retaining API backwards compatibility prevents refactoring and necessarily causes technical debt to balloon.