The GTK3 Port Of Firefox Is Making Progress, Firefox Can Run On Wayland

[Karl Napf]

Thanks for the tip. Yes, I think he is over the top. He is complaining a lot about Ubuntu-specific changes to the Gtk+ implementation, and making somewhat crazy claims about the lack of multiscreen support in Gtk+ (as if that has anything to do with Gtk+). I dunno, I worked through similar challenges and didn't find them so problematic. I prefer Xfce over Unity for my own needs, but I found that my apps moved from Gtk+2 to Gtk+3 without any issues, nothing beyond the normal involved in upgrading a major release of a toolkit.

I understood that blog post to be about his experience with gtk after doing the major version upgrade of his application to gtk3.

My personal experience (as someone who finds C++ to be more trouble than it's worth: there's the background) is that Qt is extremely annoying in many ways, not any less so than Gtk+. From my point of view, Gtk+ is actually far more conservative than Qt in terms of breaking legacy code: if anything, Gtk+ suffers from a lack of progress due to some really antiquated methodologies (see: grids) being maintained in order not to shake the boat too much.

My experience with Qt upgrades were generally very positive. If something did not work in x.y.0 it was fixed in x.y.1 if there was a bug report about it. Developers tend to be very responsive, especially about regressions.

Yes, the major version upgrade to Qt 4 was painful, but then that stayed stable for >7 years, so it was worth it. The jump to Qt 5 is almost a recompile. There even are a couple of applications that built with both Qt 4 and Qt 5 and need hardly any ifdefs to do so.

I admit that this is a challenging time to pick a good toolkit: the UX world is changing a lot, adapting to the mobile/touch/beyond challenge in innovative ways that of course can't entirely predict how things will be in a few years. So you see a lot of flux, a lot of effort to allow rendering "flexibility", in Gtk+ and in Qt. By the way, it "amuses" me to no end that people complain about CSS in Gtk+, whereas Qt embraced web technologies 100% with QML. Gtk 3.X, Qt 5.X... they are both going to be quite ephemeral. I advise developers to NOT PANIC and stick to what they do best, make great apps with a great user experience. Wait for the dust to settle, and then, if it's really necessary, refactor your application to a different library.

First QML is one option for Qt developers. There are lots of people that like it, but also lots of applications that do what they have been done for the last 10 years or so and stay completely QWidget based. I would not call that "100%".

QML is also not a web technology. Basically it is just a description of how items (rects, webviews, whatever) are arranged that is parsed once and turned into a data structure that is then shoved into the GPU for rendering. Javascript is an option to make that structure more dynamic and is purely optional, even though it is a very powerful option and there are people that do complete programs in QML and Javascript. But you can just as well wire a QML UI up with C++ business logic.

AFAIC there is nothing comparable available in the gtk world, so I am not surprised that people with that background mistake it for web technology due to its Javascript option.

[liam]

I'm a fan of Qt and all, but come on. That's not true at all. 3.12 doesn't FORCE "client side decorations" (I've already questioned the use of that phrase in an above post). It does encourage them though.
HOWEVER, the fact that CSDs don't/didn't have a reliable (or any...) fallback for non-Gnome/Gnome-based (e.g. Cinnamon) window managers was horrible planning and showed exactly how much they care about non-Gnome programmers... AKA not a bit.

I agree with very, VERY few gnome decisions (many more in gtk) but I think, as I've said many times before, that gtk/gnome would be the better if they only worked on Linux. That's pretty much the case now, as the devs focus on Linux but accept patches for other platforms. This is the best use of their resources and gives Linux the opportunity to develop a native tk like the other major platforms.
However, if the gnome devs were more amenable, a long term change to EFL would be my preference (yeah, it's cross platform but that's completely besides the point).

[psychoticmeow]

I agree with very, VERY few gnome decisions (many more in gtk) but I think, as I've said many times before, that gtk/gnome would be the better if they only worked on Linux. That's pretty much the case now, as the devs focus on Linux but accept patches for other platforms. This is the best use of their resources and gives Linux the opportunity to develop a native tk like the other major platforms.
However, if the gnome devs were more amenable, a long term change to EFL would be my preference (yeah, it's cross platform but that's completely besides the point).

What are the best aspects of EFL?

Actually, I'm going to install Enlightenment and have a play for the first time in 10+ years.

[boudewijnrempt]

CSS styling

What surprises me most is that nobody seems to remember that Qt has had CSS styling of widgets for ages... At least since 2006 or so. It didn't work very well, of course, but then, the GTK developers at the Desktop Summit in Berlin admitted that CSS styling in GTK also didn't work very well and told people to wait for GTK4 which was when they were expecting to "get it right".

As for file dialogs... Of course Qt shows the actual GTK file dialog on Gnome, if the author of the Qt application has used the static QFileDialog api. QFileDialog in Qt4 has quite a few annoyances, one of which is that if you use the non-static api, it only selects the native file dialog in KDE (where the AcceptSave flag is broken) and OSX; the Windows and GTK native dialogs are only shown if you use the static API. In practice, this means you want to use the static API everywhere except on OSX, which is a bit unfortunate.

[yogi_berra]

Oh, come on, calm down.

There are not that many gtk devs: They need to concentrate on their priorities. There is no use calling any of them names, just because their priorities are different from yours: That will only discouraging people from working on the library.

Check the statistics yourself: 90% of the commits in the last 30 days where done by 5 people (check ohloh). Those 5 people do a really heroic job at improving GTK, so please be more respectful.

[talvik]

Eclipse also went Gtk3 to Gtk2

Removed

[alazar]

As far as I'm concerned, Qt is a C++ framework while GTK+ is a toolkit. That being said, you're just saying that, for everybody that wants a "native" application in linux to ditch their code an do it over again in Qt because you don't want to have Gtk+ widgets in it?

Firefox: "what should we do... drop our already existing and stable code shared across platforms and use Qt to support linux or simply use a toolkit like GTK+?"

Mac, Windows have their own tookits and you want to drop the one Linux has had for years. I don't like the direction gnome is going to, but that doesn't make Gtk any worse than before. At least now it looks like a modern toolkit rather than something developed for Win' 95. In fact, Mint guys seems to have developed a very nice "classic" experience with this all criticism Gtk.

PS: If I'm wrong with any of my assumptions, sorry.

[talvik]

Exactly. Too bad Eclipse has moved to GTK3. I should try Intellij IDEA...

Oh, and let's not forget GIMP is also moving to GTK3. Probably in 2018 though

Eclipse Luna released today, thankfully, uses GTK2 by default!
I've tried a couple of nightly builds with GTK3 and it was simply unusable. A complex interface like Eclipse using Adwaita looks terrible, Adwaita's mega padding leaves no space for the editor. And since Gtk3 breaks themes every minor release, Adwaita is the only option.

[oleid]

A very cheap excuse, couldn't you come up with something better which is not so obviously just a petty excuse? They could easily create a small wrapper library which is linked against the c++ stack and gets dynamically loaded by GTK or even preloaded.

AFAIK gtk has no plugin infrastructure for anything. And possibly not the man power to add that stuff. Adding linking dependencies on c++ to the core library is out of question... Not a pretty excuse.

This should be part of the GTK distribution as obviously it does not exist/work anymore or it would be included in distributions.

It was never part of any distribution, because nobody cared enough about file dialogs.

Qt has been supporting GTK file dialogs for many years. At least since 2008.

Not on my desktop.

Yes we are, e.g. Chrome did this before they switched toolkit and also look at all those extensions that are created e.g. for firefox, libreoffice, etc

Perfect examples, really... Most of them use their own toolkit anyway. Any pure gtk app that has kde file dialogs? Any kde app, that has gtk file dialogs?

And the GTK developers are too arrogant to include any of these solutions into their toolkit. They'd not even need to develop it on their own, they could just copy an existing solution.

The only existing solution I know is the ld_preload wrapper. You can't include that into gtk. Distributions could provide it, however obviously, there is not enough interest. If YOU would contact the gtk developers and ask politely under what circumstances what method for using native dialogs could be added to the library AND develop the code yourself instead of whining in this very forum, then it would surely be included. But there are more pressing issues than this and gtk is understaffed anyway.

[Daktyl198]

As far as I'm concerned, Qt is a C++ framework while GTK+ is a toolkit. That being said, you're just saying that, for everybody that wants a "native" application in linux to ditch their code an do it over again in Qt because you don't want to have Gtk+ widgets in it?

Firefox: "what should we do... drop our already existing and stable code shared across platforms and use Qt to support linux or simply use a toolkit like GTK+?"

Mac, Windows have their own tookits and you want to drop the one Linux has had for years. I don't like the direction gnome is going to, but that doesn't make Gtk any worse than before. At least now it looks like a modern toolkit rather than something developed for Win' 95. In fact, Mint guys seems to have developed a very nice "classic" experience with this all criticism Gtk.

PS: If I'm wrong with any of my assumptions, sorry.

You make a very good point with Mint. GTK+ as a ui-toolkit is actually really nice, but it needs more than just Gnome managing it if it wants to go further. Gnome is not the only GTK DE, yet it seems like the non-Gnome GTK-using DEs/devs don't really speak up about the direction of the the toolkit.

If they got involved more, I could see GTK becoming something beautiful. But as of this moment, I see Qt being above GTK in many ui-related aspects (we can't really compare non-UI related aspects since that's not what GTK is for).

P.S. If Firefox decided to use Qt as their interface, they wouldn't have to manage separate Windows/OSx/Linux/whatever code, it would all be handled by Qt so it would reduce the LoC and maintenance required on FF (at least on the interface level). And since 95% of FF is written in C++, it would match up better than GTK+ with C++ bindings/wrappers/whatever.