GTK4 Development Code Just Received 100+ Commits Dropping Old Stuff

[phoronix]

Phoronix: GTK4 Development Code Just Received 100+ Commits Dropping Old Stuff

Development on the GTK+ 4.0 tool-kit continues moving along and this weekend has seen 100+ commits dropping various deprecated and outdated code...

http://www.phoronix.com/scan.php?page=news_item&px=GTK4-Cleaning-House-100

[enihcam]

I think GTK needs to be dropped. QT is the future of Linux desktop.

[jacob]

I think GTK needs to be dropped. QT is the future of Linux desktop.

That would be terrible. I can't stand Qt, both as a user and as a developer.

[Kemosabe]

That would be terrible. I can't stand Qt, both as a user and as a developer.

Excuse me? It has one of the cleanest and elegant APIs I know. It is super flexible and uses modern language features and comes with an exceptional good documentation.

[sunweb]

Sooo... Will themes be broken again?

[jacob]

Excuse me? It has one of the cleanest and elegant APIs I know. It is super flexible and uses modern language features and comes with an exceptional good documentation.

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.

[Luke]

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.

[PyroDevil]

I think GTK needs to be dropped. QT is the future of Linux desktop.

That doesn't make any sense. They are different projects, with different goals and features.

GTK is programmable with C and a lot of other languages. Qt is programmable with C++, python and maybe 2 or 3 other languages.

GTK integrates nicely with gobject, and dropping gobject too, would make it necessary to reimplement a lot of other libraries, including gstreamer.

[Anvil]

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

[estan]

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

Hm, I use the Clang static analyser all the time. It works just fine. I even have it turned on in Qt Creator all the time, and it has saved me many times. Why would the use of MOC interfere with static analysis? It just preprocesses into regular C++.

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.

This is just false, you can connect to all three of those:

#include <QCoreApplication>
#include <QDebug>
#include <QObject>
#include <QTimer>

void freeFunction() {
    qDebug() << "free function";
}

static void staticFunction() {
    qDebug() << "static function";
}

int main(int argc, char *argv[]) {
    QCoreApplication app(argc, argv);

    QTimer timer;
    timer.setInterval(500);

    QObject::connect(&timer, &QTimer::timeout, staticFunction);
    QObject::connect(&timer, &QTimer::timeout, freeFunction);
    QObject::connect(&timer, &QTimer::timeout, []() { qDebug() << "lambda"; });

    timer.start();

    return app.exec();
}

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.

This is wrong as well, and I guess based on the same misconception as above. Only when you use the old string based connect syntax (SIGNAL/SLOT macros) will you lose some type safety.

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.

These are objections I can actually understand, even if it's not something that has ever bothered me. I do object to the description "proprietary" though. Qt's drawing API is not proprietary, it's just different from Cairos (which I wouldn't call standard).

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.

The uglyness is more of a personal opinion, so I won't comment on that. But to say that Qt fits in poorly with the environment it runs under compared to Gtk+? I've always had trouble with Gtk apps looking out of place on Windows and Mac OS X. I think Qt is doing much better when it comes to native look.

If you're talking about the look of Qt apps under GNOME or other Gtk+ based environments, there's a Qt style plugin you can use that will. I even think it will use your current Gtk style engine + style.

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.

I think you're missing some things I'm not saying Qt is perfect (far from it). But having worked on both Gtk and Qt apps, I can say without a doubt that I find the experience with Qt more pleasant.