4 ms·

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 exa

by 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

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.