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

[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 .

[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.

[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)

[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.

[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.

[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)?

[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.

[dkasak]

The 2-to-3 port for my applications was pretty simple, and I have a bunch of custom widgets, cell renderers, etc. I expect the same when moving to 4. Regarding firefox, I believe they're stuck on 2.x because they need to support distros that haven't moved to gtk 3.x yet. Firefox would hardly use any gtk at all frankly - it only uses gtk+ on Linux, and it doesn't take a lot of thought to realise that this would be for the non-html elements only ( ie navigation buttons ).

[Delgarde]

Regarding firefox, I believe they're stuck on 2.x because they need to support distros that haven't moved to gtk 3.x yet. Firefox would hardly use any gtk at all frankly - it only uses gtk+ on Linux, and it doesn't take a lot of thought to realise that this would be for the non-html elements only ( ie navigation buttons ).

Actually, it's more complicated than that. One, they're partly stuck with GTK+2 because that's essentially part of the plugin ABI... they can't change that, because plugins like Flash will fail if Firefox isn't providing the GTK+2 interfaces (and plugins can't update to GTK+3 because doing so would conflict with the GTK+2 interfaces provided by Firefox... chicken and egg.) Though that problem presumably solves itself once they drop support for NPAPI plugins.

For the rest of the application, it's odd. Firefox doesn't use GTK+ directly for the UI - they use their own XUL framework. But as I understand it, GTK+ is somehow used internally... I don't know details, but I think it has something to do with platform-native look-and-feel...

[dkasak]

Actually, it's more complicated than that. One, they're partly stuck with GTK+2 because that's essentially part of the plugin ABI... they can't change that, because plugins like Flash will fail if Firefox isn't providing the GTK+2 interfaces (and plugins can't update to GTK+3 because doing so would conflict with the GTK+2 interfaces provided by Firefox... chicken and egg.) Though that problem presumably solves itself once they drop support for NPAPI plugins.

For the rest of the application, it's odd. Firefox doesn't use GTK+ directly for the UI - they use their own XUL framework. But as I understand it, GTK+ is somehow used internally... I don't know details, but I think it has something to do with platform-native look-and-feel...

Right. I forgot about Flash. Nasty