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

[ssokolow]

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

It's basically the same thing QGtkStyle does. They sometimes request icons from the system theme (though that's being phased out for consistency), they query the widget theme for color scheme information, and they delegate to the theme to draw things like buttons and form fields.

[anda_skoa]

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

They could do the same thing any non-GTK based browser does: run the plugins out-of-process.
Would also be safer and not compromise the stability of the browser if a plugins crashes.

Cheers,
_

[Vistaus]

Well, Xhrome still uses GTK 2 .

Eh, I thought Xhrome moved to Aura?

[TheBlackCat]

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.

So only projects that use deprecated APIs have difficulty porting, which means the fact that a project has difficulty porting is enough to show that it is using deprecated APIs. Circular logic at its best. You don't actually need to know anything about the project's code base, the mere fact that it contradicts your claim is enough to ignore it entirely.

It couldn't possibly be that your experience with your single project is not representative of all projects of all kinds.

[leipero]

Eh, I thought Xhrome moved to Aura?

Typo, wanted to say Chrome , i think it's still GTK 2, at least it was ~4 months ago when I modified some themes, and Chrome reacted to GTK 2 .

[Delgarde]

They could do the same thing any non-GTK based browser does: run the plugins out-of-process.
Would also be safer and not compromise the stability of the browser if a plugins crashes.

They do, and have for a very long time.... that feature was added to Firefox 3.6 back in 2010 or so.

But that doesn't change the fact that at least one part of Firefox is required to link to GTK+2, and therefore cannot be linked to GTK+3. A significant part of their move to GTK+3 was to re-arrange library code to allow them to simultaneously build against both GTK+ versions... 3 for the browser itself, 2 for the plugin container.

[anda_skoa]

They do, and have for a very long time.... that feature was added to Firefox 3.6 back in 2010 or so.

Ah, yes, I thought they did, but the other comment made it looks like they didn't.

But that doesn't change the fact that at least one part of Firefox is required to link to GTK+2, and therefore cannot be linked to GTK+3.

Sure, but that's not the browser, just the plugin host which likely doesn't need much changes at this point.

So I wouldn't consider "need GTK2 for plugins" to be a reason to hold back a GTK3 port of the browser.

A significant part of their move to GTK+3 was to re-arrange library code to allow them to simultaneously build against both GTK+ versions... 3 for the browser itself, 2 for the plugin container.

Sounds like a lot of effort to allow simultanious building against two version of a library if you only need one at a given time.
Would be much easier to just build the browser against the target version and the plugin host against the self inflicted compatibility version.

Cheers,
_