GNOME Developer On GTK4: State-of-the-Art of Toolkit Support

[Delgarde]

If it is so trivial, how come GIMP has not updated to the latest version of the GIMP toolkit (and may not support version 3 until version 4 comes out, if ever)?

Apparently you ignored the entire second paragraph of my message? The bit that noted that porting from GTK+2 to 3 was trivial... as long as the GTK+2 code was well maintained, avoiding the use of deprecated APIs, etc?

And GIMP is a chronically under-resourced project that's had nothing to do with the development of the toolkit since the days of GTK+1. So while I'm not familiar with their codebase, I suspect it's heavily reliant on APIs that were deprecated long ago, but which they've not had the time to do anything about. At which point porting *is* difficult, because you've saved up all your technical debt until it becomes an obstacle to getting anything done, and it all has to be addressed at once.

[TheBlackCat]

I can't speak to GTK+ 3 to 4, but with 2 to 3, it was trivial to the point where many Gnome apps supported it as a compile-time switch... the same code would work against both, barring a small number of #ifdefs.

If it is so trivial, how come GIMP has not updated to the latest version of the GIMP toolkit (and may not support version 3 until version 4 comes out, if ever)?

[uid313]

I can't speak to GTK+ 3 to 4, but with 2 to 3, it was trivial to the point where many Gnome apps supported it as a compile-time switch... the same code would work against both, barring a small number of #ifdefs.

The catch is that that was only true if you'd been keeping up maintenance on the app. APIs dropped in GTK+ 3 were generally marked as deprecated in GTK+ 2 well in advance, so if you took advantage of that notification and kept your code clean, you were fine. But if you didn't - if you kept using deprecated APIs right up to the point where you had to port to GTK+ 3, then it was going to hurt... you'd need to do a lot of changes all at once, a "big bang" approach.

And I assume the same will be true for porting to GTK+ 4... that any code which compiles cleanly against current GTK+ 3 will probably be simple enough to port, but code that's full of deprecation warnings will be problematic.

Still Firefox, GIMP and Electron (which powers Spotify, Atom and VS Code) haven't been ported yet. But maybe it is simple, I don't know.

[doom_Oo7]

On the other hand, now GTK+ have "state-of-the-art" pipeline that can handle most of the modern backends. It's not shiny (because, by definition, these are backends), but it's better than what Qt can do today.

Actually they just followed in the tracks of Qt introducing a scene graph with the same "multi-backend" concept... except it was done in Qt three years ago with Qt5.

[ssokolow]

That doesn't say anything about the inferiority or superiority of Qt over GTK+. Qt might be better at some stuff for now, but they apparently didn't fight the same battles. For sure, GTK+ 3 was a hard pass for the project because it needed a lot of deep refactorizations, and so the GTK+ devs took some delay on some fancy new UI features that Qt has now. On the other hand, now GTK+ have "state-of-the-art" pipeline that can handle most of the modern backends. It's not shiny (because, by definition, these are backends), but it's better than what Qt can do today. So here the state today and in a few months, it might be completely different, maybe GTK+ will be able to do incredible stuff that Qt can only dream of (thanks to the refactorizations), or maybe Qt's vision was better and everyone will move to it. Only time will tell.

For a long time, I've been using a blend of LXDE and KDE, so, regressions aside, I don't really care much about anything but how difficult it is to accomplish my programming goals.

In fact, I have little interest in the QML stuff Qt has been focusing on in the last few years. (Aside from as a way to do GPU offload in a possible multi-axis image browser I have as a not-at-all-near-future idea to explore.) The important point is, my experience has been that GTK's APIs are lower level and the functionality you get without full-sale buy-in to the GNOME libraries is much more restricted.

For example, Qt not only gives things like configurable toolbar and panel floating/repositioning for free, you can load/save that plus the window geometry to the XDG-specified locations via QSettings in three lines (containing five method calls)... I never found a GTK+ equivalent to that.

In PyQt5, saving them via a QMainWindow event handler would look like this...

settings = QSettings()
settings.setValue("mainwin_geometry", self.saveGeometry())
settings.setValue("mainwin_state", self.saveState())

...and QSettings automatically handles deferring the write to accumulate data on either a timer or application shutdown. That's another thing I couldn't find ready-made without opting in to using GConf/dconf/whatever they call it these days. (I actually ended up rewriting that from scratch in one of my PyGTK apps)

[Duve]

Given how long it took Firefox to switch to GTK3 (it's not even fully free of related bugs yet), it will take forever with GTK4...

All things considered, Firefox is rather large which had quite a bit of complications that they could not control (flash)... and the effort to the GTK3 port only picked up stream in the last few years. They (and GIMP, whom has been working on a new engine the entire time) don't really set the bar for how much difficulty it would take to port to GTK3. They are rather unique cases.

[leipero]

Given how long it took Firefox to switch to GTK3 (it's not even fully free of related bugs yet), it will take forever with GTK4...

Well, Xhrome still uses GTK 2 .

[Delgarde]

Given how long it took Firefox to switch to GTK3 (it's not even fully free of related bugs yet), it will take forever with GTK4...

That wasn't much to do with the port to GTK+3 itself though... more to do with architecture shifts within Firefox to permit it. And since that's already done now, it's not necessary to repeat the process for GTK+4...

[Delgarde]

"Even better, the absolute majority of applications will gain this for free once they port to Gtk+ 4 series."

But how trivial is it to port your applications from version 3 of GTK to version 4?

I can't speak to GTK+ 3 to 4, but with 2 to 3, it was trivial to the point where many Gnome apps supported it as a compile-time switch... the same code would work against both, barring a small number of #ifdefs.

The catch is that that was only true if you'd been keeping up maintenance on the app. APIs dropped in GTK+ 3 were generally marked as deprecated in GTK+ 2 well in advance, so if you took advantage of that notification and kept your code clean, you were fine. But if you didn't - if you kept using deprecated APIs right up to the point where you had to port to GTK+ 3, then it was going to hurt... you'd need to do a lot of changes all at once, a "big bang" approach.

And I assume the same will be true for porting to GTK+ 4... that any code which compiles cleanly against current GTK+ 3 will probably be simple enough to port, but code that's full of deprecation warnings will be problematic.

[Creak]

There will always be this battle between GTK+ and Qt, I'm afraid...

If you prefer Qt over GTK+, or the opposite, that's fine. No one will come at your house to change your mind.

I like GTK+ because I like GNOME and what the devs are aiming at -- no matter the handful of guys screaming out that GTK+ and GNOME 3 altogether are a complete disaster. And I'm not very fond of Qt, because I'm not fond of KDE and its rather conservative vision, and all that is completely subjective.

That doesn't say anything about the inferiority or superiority of Qt over GTK+. Qt might be better at some stuff for now, but they apparently didn't fight the same battles. For sure, GTK+ 3 was a hard pass for the project because it needed a lot of deep refactorizations, and so the GTK+ devs took some delay on some fancy new UI features that Qt has now. On the other hand, now GTK+ have "state-of-the-art" pipeline that can handle most of the modern backends. It's not shiny (because, by definition, these are backends), but it's better than what Qt can do today. So here the state today and in a few months, it might be completely different, maybe GTK+ will be able to do incredible stuff that Qt can only dream of (thanks to the refactorizations), or maybe Qt's vision was better and everyone will move to it. Only time will tell.