3 ms·

It's kinda ironic that they realized (and admitted) this more than 15 years later. Meanwhile, there's Cinammon, MATE, pantheon, moblin, clutter, mutter, unity,

It's kinda ironic that they realized (and admitted) this more than 15 years later. Meanwhile, there's Cinammon, MATE, pantheon, moblin, clutter, mutter, unity, and several others that went into being hardforks at this point because they didn't agree with GNOME's Human Interface Guidelines. It's also ironic that the only thing using GTK2 components on every system at this point is GIMP. The problem with upstream GTK's workflow is that they have so many breaking releases and their own versioning scheme that is completely different from any other project, making it impossible to rely upon. A UI component framework should be reliable, stable in its API and scene graph, and not break with any second release every couple months.

kelnos 2y ago
> The problem with upstream GTK's workflow is that they have so many breaking releases and their own versioning scheme that is completely different from any other project Not sure what you mean. GTK uses semver; any 2.x or 3.x or 4.x release will work with software built around a previous release with the same major version. You can argue that GTK breaks API/ABI and increments their major version too often (I'm not sure I'd agree with that, but you can certainly argue it), but, outside of bugs, I don't recall instances where apps had to be modified to continue to work with new releases in the same major version of GTK. I do think it's notable that GIMP is still on GTK2, and the GTK3 porting effort has gone on for many years now. But I think it's also notable that GIMP is the exception, not the rule. On my system, for example, only GIMP requires GTK2, and I have over 100 binaries in /usr/bin/ that link to GTK3
- IAmLiterallyAB 2y ago
  I remember GTK themes used to break every couple releases. Is that not an API break?
- cookiengineer 2y ago
  GTK doesn't use semantic versioning. Every uneven minor version is a development cycle, every even minor version is a stable cycle. And as it happened so often, every dev cycle things broke down, because of intertwined dependencies of GTK, gjs and glibc (and gobject introspection bindings). See also: https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta... I also think you're kind of proving my point. If the project that is supposed to be _the demo use case_ of the _GIMP Tool Kit_ and needs more than a decade to update its scenes, views, and widgets...then maybe this is not the right toolkit for anyone, because pretty much every CEO will go rogue when they see the development time needed to port anything to GTK. And it doesn't have to be like that. It's an architecture design decision they made, where they also chose vala as their own NIH programming language to integrate things over other more established options. Same goes for glibc and gjs which meanwhile has so many bugs I can probably exploit it with a heap spraying exploit from 10 years ago, as it conceptually is yet another hard forked project inside the GNOME ecosystem which can never be updated with its upstream project dependencies/origins. My point is that the GNOME project introduced maintenance burden upon themselves, and that's what's killing the GTK ecosystem. And they themselves could have avoided that. (Apart from the outdated documentation whose example demos don't even compile, whereas the getting started effect with QML is a matter of minutes, not days) I don't wanna derail this discussion too much. It's great that GTK is evolving and adapting. I just wish they would focus on ease of use rather than inventing their own tech stack wherever possible.
  - crashdancer 2y ago
    The issues you mention here are mostly not relevant anymore or they're unrelated to GTK proper. The GIMP GTK3 port took forever because it's a giant app with lots of complex widgets and a tiny amount of developers. Most other apps didn't take that long to port. Also Vala isn't really used much in GNOME anymore. ElementaryOS is the main user of it now. >Same goes for glibc and gjs which meanwhile has so many bugs I can probably exploit it with a heap spraying exploit from 10 years ago, as it conceptually is yet another hard forked project inside the GNOME ecosystem which can never be updated with its upstream project dependencies/origins. I honestly have no idea what you're referring to here. GNOME has never forked glibc. And GJS is periodically updated to the latest spidermonkey.

kelnos 2y ago

> The problem with upstream GTK's workflow is that they have so many breaking releases and their own versioning scheme that is completely different from any other project Not sure what you mean. GTK uses semver; any 2.x or 3.x or 4.x release will work with software built around a previous release with the same major version. You can argue that GTK breaks API/ABI and increments their major version too often (I'm not sure I'd agree with that, but you can certainly argue it), but, outside of bugs, I don't recall instances where apps had to be modified to continue to work with new releases in the same major version of GTK. I do think it's notable that GIMP is still on GTK2, and the GTK3 porting effort has gone on for many years now. But I think it's also notable that GIMP is the exception, not the rule. On my system, for example, only GIMP requires GTK2, and I have over 100 binaries in /usr/bin/ that link to GTK3

IAmLiterallyAB 2y ago
I remember GTK themes used to break every couple releases. Is that not an API break?
cookiengineer 2y ago
GTK doesn't use semantic versioning. Every uneven minor version is a development cycle, every even minor version is a stable cycle. And as it happened so often, every dev cycle things broke down, because of intertwined dependencies of GTK, gjs and glibc (and gobject introspection bindings). See also: https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/ https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta... I also think you're kind of proving my point. If the project that is supposed to be _the demo use case_ of the _GIMP Tool Kit_ and needs more than a decade to update its scenes, views, and widgets...then maybe this is not the right toolkit for anyone, because pretty much every CEO will go rogue when they see the development time needed to port anything to GTK. And it doesn't have to be like that. It's an architecture design decision they made, where they also chose vala as their own NIH programming language to integrate things over other more established options. Same goes for glibc and gjs which meanwhile has so many bugs I can probably exploit it with a heap spraying exploit from 10 years ago, as it conceptually is yet another hard forked project inside the GNOME ecosystem which can never be updated with its upstream project dependencies/origins. My point is that the GNOME project introduced maintenance burden upon themselves, and that's what's killing the GTK ecosystem. And they themselves could have avoided that. (Apart from the outdated documentation whose example demos don't even compile, whereas the getting started effect with QML is a matter of minutes, not days) I don't wanna derail this discussion too much. It's great that GTK is evolving and adapting. I just wish they would focus on ease of use rather than inventing their own tech stack wherever possible.
- crashdancer 2y ago
  The issues you mention here are mostly not relevant anymore or they're unrelated to GTK proper. The GIMP GTK3 port took forever because it's a giant app with lots of complex widgets and a tiny amount of developers. Most other apps didn't take that long to port. Also Vala isn't really used much in GNOME anymore. ElementaryOS is the main user of it now. >Same goes for glibc and gjs which meanwhile has so many bugs I can probably exploit it with a heap spraying exploit from 10 years ago, as it conceptually is yet another hard forked project inside the GNOME ecosystem which can never be updated with its upstream project dependencies/origins. I honestly have no idea what you're referring to here. GNOME has never forked glibc. And GJS is periodically updated to the latest spidermonkey.