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

[emblemparade]

It's not just the modern backends that are exciting here (GNOME and Cairo always supported lots of backends, including a weird JavaScript/HTML backend), but also the new scene graph that renders the window as a whole rather than the classical one-widget-at-a-time. I think that plus Wayland is going to lead to practically no tearing anymore, even on very complex GUIs on low-power systems.

I've ported lots of code, some quite complex, from GTK+2 to GTK+3, and it honestly wasn't too hard. A few deprecations, a few different ways of doing things (all of them improvements), and that's it. (Theme developers, however, had a terrible time, as everything changed.) From what I see now the leap from GTK+3 to GTK+4 is much smaller. Mostly they are just totally deleting the things that were deprecated before (that's what jumping to a new major release number entails) and changing the underlying technologies. The API is incremental progress. Oh, and of course some new widgets if you want to use them.

[shmerl]

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

[bug77]

I think you can fathom porting fro GTK+2.x was a lot longer process than 3 to 4.

Actually, no, I don't.
I've read that GTK3 was supposed to be the disruptive iteration, but since I'm not familiar with GTK, comments on how easy it would be to move from GTK3 to GTK4 is what I'd be most interested in.

[RahulSundaram]

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

3 to 4 is a much smaller change to the new development process.

[Creak]

Actually, no, I don't.
I've read that GTK3 was supposed to be the disruptive iteration, but since I'm not familiar with GTK, comments on how easy it would be to move from GTK3 to GTK4 is what I'd be most interested in.

I ported an app in Python from GTK 2 to GTK 3.

Knowing that I'm a programmer, but I don't know Python nor GTK+ very well, it took me two to three nights to port it (https://github.com/MightyCreak/diffuse). Basically, once you've seen the couple of code you need to change (a constructor that take one more parameter or one less, a new enum here, a new type there, ...), it's pretty straightforward and just a matter of changing the code and verifying it still works as excepted.

I only had problem with the grid and the status bar. I had to remove an info in the status bar because the widgets didn't want to resize properly otherwise. I strongly think this is due to the ugliness of the code rather than GTK+ API, but I'll work on that later in order to have a cleaner and more modular code.

Edit:
And as said, even though changing the major version seems like a huge improvement, it's mainly based on a new versioning system. On the software dev side, it's more a matter of a big clean: if you don't use any obsolete stuff in your GTK 3 app, you should not have any trouble porting it to GTK 4.

And lastly, GNOME is in charge of a lot of their own softwares, so it's in their interest to have a smooth GTK 3 to GTK 4 porting process.

[iznogood]

A platform that is used by the applications it's own developers create, is not a platform.
there is not a single job opening in the entire UK (as an example) that requires GTK.
If you only look for software developed at universities, then it is fine

[ssokolow]

I was driven to switch from GTK+ 2.x to Qt by all of the "You're not running GNOME 3? Here. Have a regression." bugs that kept cropping up in GTK+ 3.x. (things like "Let's show the regular menu bar AND the unified menu bar at the same time")

Once I did, I realized how much GTK+ APIs really were a paler imitation of Qt's.

(It also didn't help that the pygtkcompat porting shim crashed my apps on startup the last time I tried it, which significantly narrowed the gap in effort between porting to GTK+ 3.x and porting to Qt.)

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

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

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