GTK 4.0 Toolkit Officially Released

[rastersoft]

And will you help in fixing that opensource software or the answer is invariably no?

Why should him? Everybody knows that free/open source code grows in the trees.

[zxy_thf]

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.

Yeah I agree, Qt's signal-slot works way differently with MT, and requires an event loop.
OpenGL + MT is a complete disaster. The function pointers are not even guaranteed identical among contexts/threads (don't remember details but on Windows things are really funny).
For OpenGL case I don't think Rust would help here.

For C vs C++, my point is not only about the toolkit, but also the whole gnome ecosystem, because the blog post is about the whole gnome (sorry if anyone is confused).

The complete statement of my post at #9 is:
For some reason I don't know, the majority of Gnome projects were written in C.
We can certainly debate whether it's feasible to use C++ for library development, but for application development, using C is really inefficient, and even C++ is not so attractive given the success of electron-based VSCode.
Thus, while the core part of Gnome ecosystem might be Okay, the applications part may not be able to lure enough new developers.

[andreano]

C++ is garbage

If C had some of the useful zero-cost abstractions, like templates, constexpr and static_assert, I would be open to agree, if comparing to C++. My criticism of C (and C++) though, would be about UB: The compiler is allowed to silently delete your code instead of failing, which undermines its role as "portable assembly" – a faithful machine-near language. I hope to learn Zig next year, and see if it is a better C in some ways.

[kpedersen]

Don't think of C as just a language. Think of it as a solid underlying platform. The reason why Gtk+ has such great support for language bindings is because it is written in C.

The following interop examples are much more complex if C wasn't involved.

Java <-> C#
Rust <-> Java
Python <-> Perl

They all go through C. Yes, very few are truly skilled enough to write decent code in C. But it needs to be done and we do our best. Either way, the fact that compiler vendors are *finally* starting to give a sh*t about safety (i.e with sanitizers) is improving code quality considerably. So much so that for many projects, C is very easy to justify again.

[caligula]

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.

You'd lose the whole concept of zero cost abstractions doing that. I mean that's what usually happens when you need bindings, but if performance was a secondary concern, using C++ would make little sense. There are other languages that require a lot less runtime support and are happy with much simpler compilers, yet provide reasonable type safety. C++ has some features that make resource handling a bit nicer, but even then, the most popular toolkits (Qt) require tons of other build tools as well. Compare that to e.g. ImGui.

[wizard69]

My problem with C++ is that the standards group seems to be hell bent on making C++ into an unreadable mess. Too many constructs in C++ require you to carefully parse for meaning and sometimes you don’t get it right.

for GUI development what the world needs is a better Python. This is why I have looked seriously at Swift. Swift seems to generate a lot of whining in the Linux community due to its association with Apple. I guess there is little to do with hard heads but more reasonable people ought to be able to evaluate and find some good technology in Swift.

in a nut shell C & C++ just require far too much investment in time to get a solution up and running. The goal of a GUI toolkit should be the enablement of rapid development. In this regard GTK has problem and part of that is the association with C.

[Sonadow]

My problem with C++ is that the standards group seems to be hell bent on making C++ into an unreadable mess. Too many constructs in C++ require you to carefully parse for meaning and sometimes you don’t get it right.

for GUI development what the world needs is a better Python. This is why I have looked seriously at Swift. Swift seems to generate a lot of whining in the Linux community due to its association with Apple. I guess there is little to do with hard heads but more reasonable people ought to be able to evaluate and find some good technology in Swift.

in a nut shell C & C++ just require far too much investment in time to get a solution up and running. The goal of a GUI toolkit should be the enablement of rapid development. In this regard GTK has problem and part of that is the association with C.

But how many Linux-available GUI toolkits use Swift?

[Sonadow]

GTK4 looks almost identical to GTK3.

It's good for consistency but I was wishing for it to resemble GTK2 instead. For some reason the look for GTK2 appeals to me.

[mulenmar]

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.

Memory management issues are hardly the only thing Rust brings to the table, even without Cargo or the standard library, and the process of migrating from C to Rust has success stories too -- see librsvg for one, see Firefox for another (though mind filtering out the problems that are entirely a Mozilla management mess). IIRC Gstreamer was rewriting their parsers in Rust a while back.

Amazon, Google, and others are all diving in on the Rust train. Heck, even Microsoft is getting in on it... but then, they need all the help they can get. 😝

I'm not saying Rust is the end-all, be-all of classical-physics-based computer programming languages, mind -- I've read several stories about it being a poor choice for low-level network stack stuff (though dropping to C sufficed) or trying to write a Wayland compositor (because the designers of the protocol made it C-centric, plus Rust being bad with things where it may lose ownership) -- but the strengths of the language and ecosystem, and the ease with which they do so without any of the runtime costs or object-oriented design challenges go beyond what C plus a metric-ton of external tools and boilerplate can manage.

And besides... there are projects to let devs transpile all that Rust code to C code anyway, without any of the memory errors that writing C to begin with would have, for use with GCC, as well as at least two to allow GCC itself to handle Rust.

[esbeeb]

I looked at the GTK4 widget demos, and none of them jumped out at me as something I wanted to have or use in all the OSS apps I already know, and like using. My desktop is already sufficiently sexy enough, thank you very much.

Just when desktop environments like XFCE, MATE and Pantheon were settling in very nicely to GTK3, this churn had to tortuously come along and very possibly majorly set back the deliverable productivity of a very large pile of developers, package maintainers, and distro maintainers, for no really compelling reason for the end user.

That intensely high productivity cost of retooling a huge number of the widgets in apps will very likely beleaguer the OSS world for years and years. And the popularity of Desktop Linux will probably still, at that future time, be pegged right at the 2% desktop marketshare it's always had for a very long time now.

I implore any OSS developer whose salary is not bankrolled by the likes of Redhat/IBM to just continue using GTK3 for as long as feasibly possible, pretending GTK4 had never been invented, until you are pretty much dragged kicking and screaming.