KernelShark 1.0 Released After Switching From GTK To Qt

[pracedru]

Please gnome. Make an effort to have proper theming for Qt applications.

[andrei_me]

Michael Kernelshark is that project that was running a poll to choose the new logo?

[carewolf]

Not saying that there's anything bad being a hobby project, per se, it's just a fact of being a community driven open-source project.

Qt on the other hand is much more professionally done (from the code itself all the way to documentation and tooling) but it's also an enterprise product by a large corporation selling it to other large corporations.

Correction: Qt is made by a small company selling it to other companies large and small.

[carewolf]

That's true (if you're writing templaized code, which is not always what you want) , but nevertheless it feels quite archaic and strange, if you're used to modern C++. In the c++ podcasts I listen to, they wondered why there are so little Qt people on c++ conferences and they assumed, that's due to Qt having it's own kind of C++.

It is not is own kind of C++. But note all the development is in Europe, you won't find many (or any) going to US developer conferences, but Qt people are often at the European C++ conferences, contributes to the new standards and have a member in the top C++ standards comitee.

Internally Qt will also use the latest C++ features when available, but can rarely change public API to use them since the minimum there is C++11 at the moment, and was C++98 when Qt 5 was first released; and Qt takes source and ABI compatibility VERY serious (even more so than C++ does).

Note this will change with Qt6, which will up the minimum requirement to at least C++17, though the current consensus is to not change too much to maintain source compability to avoid having customers stuck on Qt5 for a decade like happened with Qt3. Still a handful of Qt classes now completely superceded by C++ looks to be going away.

[trek]

I was a strong supporter of gtk at the 1.x era, when it was the gimp toolkit, because it was opensource and plain C, as opposed to a non-free qt in C++. At the time I was using gnome 1 and it was great, faster than kde, far better than enlightenment I was using previously, that was already a giant leap forward compared to fvwm/olvwm.

Then something got broken, gnome 2 got slow and heavy like an elephant, so I switched to xfce, but still preferring gtk 2 applications. At the same time I started developing with glib (liked very much) and qt become free.

Compiz kicked off the compositing mania and the gnome 3 era begun. Xfce started to look like gnome 2, so I abandoned it in favor of lxde, but also many gtk applications disappeared from my desktop: gtk 2 -> 3 porting issues, ABI incompatibility between minor versions of gtk 3 and the usability changed too much for my taste (where is the menu bar?)

Today gtk 2 applications are hunted for a bounty (last victim: leafpad removed from debian), gtk 3 seems reached a stable point but gtk 4 is coming, lxde is migrating to qt like many applications and my desktop is a plain openbox + fbpanel with an heterogeneous mix of gtk 2/3, qt 5 and plain X11 applications (mpv, mupdf and I still can't find a substitute for xcalc that can start instantaneously under heavy load)

I think gtk development was driven too much by gnome, thus making non-gnome gtk applications second class citizens and forcing developers to do additional maintenance burden only to keep the application in a working state. On top of that, qt is now a free alternative, with an API even better stable and wider cross-platform compatibility. Anyway I hope gtk could regain its status and join again the competition in the future.

[pal666]

There's no sinking ship, Qt just serves better for writing cross-platform (GNOME, KDE, etc) applications.

qt has nothing to do with being better cross-gnome than gtk is cross-kde. qt is intrinsically better than gtk just because it is (kindof) c++ library and even kernel devs prefer c++ over c (and to do otherwise you have to lack education, though that's not uncommon)

[reavertm]

If I were to guess why Qt might want to stick to old C++ language revisions in core libraries, it would be the embedded.
Qt is primary toolkit in automotive and some obscure platforms might not even have gcc crosstoolchain available and thus no C++11 even.

[pal666]

About the STL: this is due to history.

no, this is due to obsoleteness. of qt. 1995 was in previous millenium

[pal666]

It is not is own kind of C++

i'm pretty sure real c++ has no qt keywords and no moc. if you want to look at real c++, look at gtkmm

Qt takes source and ABI compatibility VERY serious (even more so than C++ does).

care to substantiate this claim?

[carewolf]

i'm pretty sure real c++ has no qt keywords and no moc. if you want to look at real c++, look at gtkmm

If it has no preprocessors, then how do you include header files ;P You can write Qt without moc if you want to, it is just a convinience tool for writing introspective code until C++23 adds it natively.

care to substantiate this claim?

The fact that you can still use Qt 5.0 libraries compiled with C++98, with applications build with Qt 5.12 using C++17, but can't use libraries using STL from before C++11 with applications based on STL post C++11?

No, just try it. Qt works as is ABI compatible, the C++ standard library makes no such guarantees, and have broken on several occations.

I should note though that being stricter than C++ is coming at an end, Qt will be using more and more of STL to avoid unnecessary feature duplication and thus in the future be affected by STL ABI breakages like other C++ libraries and projects.