GTK 4.0 Toolkit Officially Released

[calc]

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.

That's exactly what it looks like, without Red Hat and Canonical it would likely die.

The long decline after 2010 until the uptick in 2018 also marks when Ubuntu had stopped using Gnome and switched to Unity with 11.04 until they switched to Gnome 3 with 17.10.

[Sonadow]

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.

With that kind of mindset, you should just stick with GTK1 and Qt1.

[poncho524]

Will they actually bother w decent documentation now?

[muncrief]

Good lord, can we finally use variables in themes? Or are we still stuck with hard coding thousands of colors, transparencies, sizes, and other parameters the good old fashioned 1980's way?

[Anarchy]

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.

For most apps, something along the way of electron, react native or flutter might be the way long term. they're definitely much easier to use for developing GUIs and offer quick solutions for most problems. Maybe someone who needs to do something specific will have to use java, gtk or qt, but the vast majority of homies will just stick to the dumbest simplest multiplatform toolkit. This is kinda already happening with apps such as vscode and slack -- they're kinda awful and look weird, but no one really cares.

[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.

[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.

[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.

[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?

[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.