Comment by cookiengineer | Hacker News Reader

Comment by cookiengineer | Hacker News Reader

Parent Full thread

Note that this was the case for Blender pre-2.8, too.

The issue with any software of this complexity is tech debt. If anything, GIMP should be a big warning sign about what happens if you bet on e.g. a UI framework which moves on without you.

GTK's development and release schedule is pretty aggressive, especially with the even releases being stable and the odd releases being unstable (which no other library on the planet decided to do so). A lot of cross platform software decided to a refactor to QT because of that, and I'd argue that the problem lies with upstream GTK and its failed API stability promises along the way.

In open source projects, you cannot afford to bet on unstable UI frameworks because you don't have enough time to spend on refactors like this. If every second subminor GTK version breaks your code, it's just not possible to keep up with that.

I'm actually impressed that GIMP wasn't fully abandoned because the sheer amount of code that needed to be rewritten is massive.

The extra irony here is that both apps built their own, entirely custom UIs rather than settle for dependencies on existing kits... The big difference with GIMP was that its toolkit was built to be separable from the rest of the app and eventually became its own project, while Blender's is just ... Blender.

I suspect if you described the architecture of the two apps without naming them, most devs would predict disaster for the latter. But as you say, it has not worked out this way; indeed, GTK has repeatedly dropped or... gimped... functionality that originally existed to facilitate productive interaction with the GIMP UI (such as fast custom shortcut keys), while Blender's UI remains bespoke and quirky, but also insanely powerful.

Wasn't GTK originally the GIMP toolkit? It's kind of awkward to say you shouldn't have bet on the thing you created in-house…

Of course it's gotten a life of its own since, but that wasn't a thing when GIMP picked it.

GIMP got stuck in the 2.8 branch because of the GTK3 changes back then, which changed a lot in the display tree and structure of the "css graph" (not sure how to describe it properly). I think that was also when they introduced their variants of expandable boxes similar to flexbox, but maybe a dev finds this and can chime in with more details on that.

I'd argue that GTK's goal of transforming into something more modern kind of lost GIMP because it was moving too fast.

I'm not blaming GTK for that, I get it, and GNOME has its goals and everything. But they're changing technologies so fast that nobody can keep up with it outside their gitlab bubble. Just thinking of the Vala introduction and GIR, for example, makes me think of never wanting to bet on their ecosystem.

They are kind of alienating themselves with the not-invented-here syndrom and too many experimental innovations that have similar already adopted counterparts in the language ecosystem.

I was investing big in gtk as my main ui toolkit (writing complex widgets, containers and rendering via “engine” interfaces), but all this 3+ pissed me off quickly. Gnome was, and is, how you lose everyone around except for yourself and that abstract idiot you’re developing for, which is often the same person.

Inkscape which in my opinion has an advanced UI like GIMP has adopted GTK3 for a while and is starting to transition to GTK4 ready.

Note that inkscape has around 70-80 part time developers, and even a project this size is reluctant to keep up with GTK.

My projects (written by a single part time dev) can never keep up with GTK. So I think you are actually arguing against GTK when it comes to resources necessary to use GTK, without realizing it.

Inkscape is a huge development project and most open source projects are way smaller than that, maintained by less than 5 people. I'd also like to point out that GTK4 is older than 6 years by now, and the UI/input flow changes that come with it (breaking old program architectures again).

GIMP originally used the Motif widget library but it was not freely available so they later created GTK back in 1996 probably because there was not many other options. It was only a few years later did projects like Gnome came out.

Lately, I was thinking that flatpack wouldn't be needed as much for Gnome dev if the libraries were more stable.

Personally I use Flatpak for two Electron apps (VSCode and Ferdium) and one GTK+ app that was never had issues with major versions (LibreOffice). GNOME apps in my case are all installed via rpm, so my experience seems to be the opposite.

GTK broke API twice in over twenty years (2->3 and 3->4), and you can parallel-install older versions. I have never heard anyone having to install specific minor releases of GTK due to breakages in the application API (theming is a different story).

I'm specifically talking about developing gnome apps. The developer documentation for Gnome uses Gnome Builder which installs a flatpack based SDK for you by default. Flatpack, it seems, is the golden path to create Gnome apps.

That's just because it lets the developer control the distribution of the app without having to find packagers in at least four distros (Fedora, Debian, OpenSUSE, Arch). Using Flatpak for the GNOME libraries is a design choice for Flatpak itself and applies to KDE apps as well.

Reply on news.ycombinator.com