3 ms·

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 h

by 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.
  - cycloptic 6y ago
    I don't think Qt4 to Qt5 is a fair comparison. The really substantial changes here are getting closer to what you would have to do to port an application from Qt Widgets to QML/QtQuick, although not quite as drastic. (The whole scene graph design has changed, but you don't need to change all of your widgets to use it effectively, only some of them) The incentive here is the same: Make a modern and flexible toolkit that works for a wide range of applications. If something is deprecated and removed with no replacement or migration plan, it's the same thing there too: customers didn't see enough of a need to pay for it to happen. AFAIK the systray icon support in GTK was removed because nobody was willing to maintain it. I don't think that's a great example because it doesn't even need to be in GTK anyway, it relies entirely on platform-specific functionality and has little to do with the toolkit. Someone can just make a library for that. (And I think Ubuntu did, but it was not upstreamed for a few reasons, one of them being that it didn't support multiple platforms) Regardless, that is the point I was getting at. The upstream policy is really not that different between these projects, you can't avoid it just by jumping ship.

by hda2 6y ago

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.
- cycloptic 6y ago
  I don't think Qt4 to Qt5 is a fair comparison. The really substantial changes here are getting closer to what you would have to do to port an application from Qt Widgets to QML/QtQuick, although not quite as drastic. (The whole scene graph design has changed, but you don't need to change all of your widgets to use it effectively, only some of them) The incentive here is the same: Make a modern and flexible toolkit that works for a wide range of applications. If something is deprecated and removed with no replacement or migration plan, it's the same thing there too: customers didn't see enough of a need to pay for it to happen. AFAIK the systray icon support in GTK was removed because nobody was willing to maintain it. I don't think that's a great example because it doesn't even need to be in GTK anyway, it relies entirely on platform-specific functionality and has little to do with the toolkit. Someone can just make a library for that. (And I think Ubuntu did, but it was not upstreamed for a few reasons, one of them being that it didn't support multiple platforms) Regardless, that is the point I was getting at. The upstream policy is really not that different between these projects, you can't avoid it just by jumping ship.