GTK 4.0 Toolkit Officially Released

[Alexmitter]

The question is will this conceivably fix the absolute mess that is GNOME and the answer is invariably no.

Ah yes, a absolute mess. Trying to be the biggest clown of the day?

[Alexmitter]

Will GTK4's GPU acceleration support OpenGL 2.0 that the Pinephone's GPU supports?

QT already supports full GPU acceleration on the Mali 400 with GL 2.0... But if GTK4 can too, then phosh will finally be competitive in performance.

The

The GLES renderer still needs work, the OpenGL Standard renderer works on the Pinephone.

[zxy_thf]

C++ is a terrible choice for a general purpose GUI library

KDE people have something to say.

You could just expose C bindings in your C++ library, but in this case you have to limit yourself to a big subset of C++ anyways making the effort kinda pointless.

Nobody stop projects doing C++ -> C ABI -> C++ header only binding.
This is how clover was implemented.

Laziness is the main reason of not doing so, to be frank.

[zxy_thf]

C++ is garbage and for lazy programmers C is much more stable and people who program with C are much better programmers

Good luck finding enough "much better programmers" for an OSS project.

Well I just realized this will not be a problem for an elitism community, but please do not make any noise about "we need more developers" in the future. Keep clam and accept the consequences of elitism.

[zxy_thf]

I'm not sure this is a programming language problem. It looks like there's no community around the gtk/gnome project, it's just red hat employees with a few contributions by canonical, debian and collabora. I guess it's fine as long as red hat is alive, but this doesn't look that great beyond that. Very disappointing, by looking at these figures I don't even see the point of making gtk4 in the first place.

I won't be worrying if the numbers are for Gtk only. Qt is on a similar boat -- mostly developed by Qt Company.

The real problem is, these statistical numbers are for the whole gnome project, covering the libraries (Gtk), the DE (mutter and gnome-shell), the application (Builder, Evince, etc).
In other words, most of the whole Gnome ecosystem (not only Gtk) is developed by RH.

[klapaucius]

C++ is a terrible choice for a general purpose GUI library because the C++ ABI breaks all of the time.

Uhm, as far as I know the last time it happened it was for C++11, and it's already been decided that there will not be ABI break for C++23 either (much to the despair of those who wanted to improve the performance of the STL). Besides, I don't see particular problems in an ABI break, for an open source library mainly used by open source applications.

[mdedetrich]

Uhm, as far as I know the last time it happened it was for C++11, and it's already been decided that there will not be ABI break for C++23 either (much to the despair of those who wanted to improve the performance of the STL). Besides, I don't see particular problems in an ABI break, for an open source library mainly used by open source applications.

If you consider name mangling as part of the ABI (which you reasonably should) then it does break very often.

The matter of fact is, C++ is much more complex than C which makes it harder to provide a reasonably stable ABI (in practical terms).

[zxy_thf]

Uhm, as far as I know the last time it happened it was for C++11, and it's already been decided that there will not be ABI break for C++23 either (much to the despair of those who wanted to improve the performance of the STL). Besides, I don't see particular problems in an ABI break, for an open source library mainly used by open source applications.

The ABI problem is not only about the breakages, but also the incompatibilities.
One can compile a C library with GCC and link it with Clang, or vise versa, but this won't work for C++.

Nevertheless, this isn't a real problem (again, think of how mesa implements OpenCL).

[klapaucius]

If you consider name mangling as part of the ABI (which you reasonably should) then it does break very often.

The matter of fact is, C++ is much more complex than C which makes it harder to provide a reasonably stable ABI (in practical terms).

But mangling is implementation specific, it's not dictated by the standard. And yet, how many binary-only applications written in GTK are you aware of, that would be affected by an ABI change, if GTK was written in C++?

[oleid]

I'm not a huge fan of Rust. Moving from C to C++ will be smoother IMO, and this process already has success stories (gcc).
In addition, smarter pointers and RAII can address quite a few memory management issues.

A small fan ist better than no fan

Anyway, huge pain points in GUI toolkits is multi threading. C++ won't help here. Sure, there are mutexes, however, the language won't help you to make sure everything is threadsafe.

I recall multithreading being a huge PITA in Qt. Especially when using GL widgets.

On the other hand, rust gui toolkits as iced or druid nicely work in multi threaded apps.