GTK4 Development Code Just Received 100+ Commits Dropping Old Stuff

[Pickup]

The whole POINT to forking 4.0 may have been that GTK Scene Kit was going to break a lot of things-and both LibreOffice and Firefox just ported to GTK3. Even if GNOME is not concerned with the MATE and Cinnamon forks, killing all that work by LibreOffice and Firefox would have been serious bad karma, possibly enough to force both of them back to GTK2 or even kill the toolkit.

GTK 3.22 is now stable, themes will never break again, and all the GTK3 ported non-GNOME apps can catch up and not worry about a moving target any more. They get Wayland support and modern theming plus the stability of GTK 2. The failure to stabilize GTK3 until now meant GNOME had to keep maintaining GTK2. They are advising that nobody outside GNOME target 4.0 until it is stable, in about two years. Until then it will be called 3.90 or such, and this will be repeated for 4.2.

A potential future issue is this: if any non-GNOME apps do use 4.0, 4.2 etc and are distributed as .deb .rpm or other system binary files and not flatpack or similar install systems, themes may have to support multiple GTK4 major versions as distros may have to have several installed at once, plus GTK 3 and possibly even GTK2. If GNOME is smart they will minimize the amount of code theme authors have to rewrite, at least the x.0 stables are supposed to be two years apart.
Meanwhile GTK 4.0 themes will probably be a hell of a lot easier to match to GTK3 themes as both will use css, than either is to match to the totally different GTK 2 themes. For the same theme to support GTK2 and GTK3 often means using a lot of otherwise avoidable images, which load from disk(slow) instead of computing on the CPU(faster). Maybe when all the GTK2 apps catch up to the now stable GTK3, we won't need to use so many images to get all GTK versioned apps to look consistant.

In one word: XFCE. Still sticking to gtk2.

[doom_Oo7]

You are absolutely right about the documentation.

But elegant, excuse me? Granted, I didn't look at the latest version, so some of my griefs maybe no longer apply. Still... Having to use MOC, which makes your code essentially impossible to be checked using a C++ static analyser. The fact that you can only connect signals to slots, not directly to any arbitrary method, toplevel function or - God forbid - a C++11 lambda. The same signal/slot mechanism (why does it exist at the first place, why?!) makes sure that any Qt code is inherently not type safe. Then if you ever hope to actually draw something on the screen, instead of the standard, clean and consistent Cairo API you have to put up with Qt's proprietary WTFic rendering API where you specify angles in 16ths of degrees (!!!) and, just for good measure, in inverse trigonometric sense.

For those who manage to tolerate this enough to actually develop some apps with it, they always integrate very poorly with the environment (presumably unless you run KDE.... but I don't and won't) and no matter what and which theme you select, I also always found that they look ugly as hell.

I might be missing something but so far I really don't see what it is about Qt that makes people talk so highly about it.

Basically, you haven't used Qt in five years.

> Having to use MOC, which makes your code essentially impossible to be checked using a C++ static analyser.

I check my Qt code with clang-anlayze, clazy, cppcheck, coverity, and cppdepends and don't have a problem.

> The fact that you can only connect signals to slots, not directly to any arbitrary method, toplevel function or - God forbid - a C++11 lambda.

Of course you can, this works since Qt 5.0 (2011/2012) : https://woboq.com/blog/new-signals-s...ax-in-qt5.html


I agree that QGraphicsView is subpar, but nothing prevents you from using another drawing library in your Qt app if you want.

[cen1]

The only thing I don't like about Qt is the overlap between some Qt features and modern C++ equivalents that appeared in 11, 14 and 17. Qt just does not feel like C++ but a whole other language of it's own. Other than that, the documentation is superb and it's easy to use.

[rastersoft]

wonder if Gnome 3.24 will be the last of the 3 series

No, it will continue receiving fixes at least until 4.x is considered stable.

[cj.wijtmans]

The only thing I don't like about Qt is the overlap between some Qt features and modern C++ equivalents that appeared in 11, 14 and 17. Qt just does not feel like C++ but a whole other language of it's own. Other than that, the documentation is superb and it's easy to use.

They probably keep it for backwards compatability. But honestly they should just remove it in a new release or something.

[starshipeleven]

In one word: XFCE. Still sticking to gtk2.

No Linux DE is sticking to gtk2, as gtk2 lacks wayland support. XFCE just has a glacial development speed, so it will get there a few years later everyone else.

[tessio]

GTK 3.22 is now stable, themes will never break again, and all the GTK3 ported non-GNOME apps can catch up and not worry about a moving target any more. They get Wayland support and modern theming plus the stability of GTK 2. The failure to stabilize GTK3 until now meant GNOME had to keep maintaining GTK2. They are advising that nobody outside GNOME target 4.0 until it is stable, in about two years. Until then it will be called 3.90 or such, and this will be repeated for 4.2

Not 4.2, but 5.0.

[pal666]

uses modern language features

like moc?

[pal666]

Why would the use of MOC interfere with static analysis? It just preprocesses into regular C++.

because you either have to understand moc-language(it is not c++), or analyse preprocessed code, not the code, written by programmer
btw, good c++ programmer would try to avoid any preprocessor

[pal666]

it's just different from Cairos (which I wouldn't call standard).

http://www.open-std.org/jtc1/sc22/wg...16/p0267r2.pdf