GTK 4.0 Toolkit Officially Released

[oleid]

yes, you have to design your program properly. c++ have tools to help you with that. shared data shouldn't be accessible to arbitrary code. you make it private and ensure it's accessed only using proper protocol.

Initial design usually isn't the problem, when done right. Refactoring usually is. Especially when being done by people who inherited the code.

[Mez']

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.

I beg to differ.

I don't think it would. On the contrary. Without the boundaries, the limited design frame and the tight control imposed by Red Hat, there would have been a much more diverse interest and the contributions would have flown. Maybe in too many directions though, which could lead to an opposite effect.

You mention a clear example of this. Red Hat rejected Canonical's ideas entirely in 2010-11 and Gnome really struggled (with UI, extensions, performance, etc...). Letting back in that big player in 2017 made a noticeable difference. Although they still have a huge issue with their limited design by not accepting externally submitted ideas. As long as they will keep a tight control of Gnome's evolution, it will remain problematic.

It's like a good sports team with a very individualist world class player which is never winning anything. Suddenly, that player is no longer in the equation (retired, sold, etc...) and somehow it liberates the others on an individual and on a collective scale while making place for new talents. Eventually, they start winning prizes because the team is no longer swallowed up by one player.

[pal666]

Keep in mind that sending values around in C++ is not necessarily thread-safe, IF they contain pointers to other data.

yes, you have to design your program properly. c++ have tools to help you with that. shared data shouldn't be accessible to arbitrary code. you make it private and ensure it's accessed only using proper protocol.

Also, std::shared_pointer can easily be mutated from different threads.

it's unclear what you are trying to say, anything can be mutated from different threads as long as they have non-const reference to it

Anyway, what libraries can you recommend?

i'm sure there's no shortage of higher-level threading libraries for c++, but i usually use manual implementations of active object and synchronized template on top of standard library

I agree, gtkmm is cleaner. But it is hardy used. Even on Linux, most GTK apps are not using gtkmm.

that's one of reasons for rust hype(see last sentence in my previous comment)

[pal666]

I don't think C++ is solving much of the issues with C.

thinking is not your strongest skill

It provides object orientation and some other goodies, but you still keep all the bad things about C like memory management, dangling pointers, null pointers (well, null in general), race conditions and deadlocks

that's what uneducated masses brainwashed by rust propaganda think. c++ provides ability to build lightweight abstractions and all those problems can be solved with them.

By using Rust you get a programing language

prototype

with the same performance

lie

, but with a lot more safety (memory, races, deadlocks, pointers and so on, are much safer)

there's c++ prototype with "a lot more safety". btw, no language will help you with "races, deadlocks", those are algorithmic errors. rust programmers apparently are unable to distinguish between "race condition" and "data race".

plus you get a lot more modern paradigms in the language

another lie. you don't get even modern paradigms already present in c++, like variadic templates

my recommendation to use Rust over C/C++ in general

my recommendation is to learn subject matter before issuing recommendations. there's no "c/c++" language, it's two different languages. some people are too stupid to learn c++, those are rust's target audience. every rust success story starts with "skipped c++ classes, suffered from c, cried for help, switched to rust"

[arQon]

There is an interesting post about Gnome (not only Gtk): https://hpjansson.org/blag/2020/12/1...ying-of-gnome/

When I saw "Graying of GNOME" in the URL I thought it was just going to be complaining about the purge of any shred of color or contrast in the UI... :P

I'm guessing having* to use C is the main factor of "Although recruitment is stable, newcomers don’t seem to be hitting their stride in terms of commits."

I'm guessing it has nothing at all to do with that, and everything to do with what happens to NIH PRs.

[AnAccount]

for anyone writing any programs, i recommend looking at c++ instead of c

Not sure if you are joking or not, but I don't think C++ is solving much of the issues with C. It provides object orientation and some other goodies, but you still keep all the bad things about C like memory management, dangling pointers, null pointers (well, null in general), race conditions and deadlocks. By using Rust you get a programing language with the same performance, but with a lot more safety (memory, races, deadlocks, pointers and so on, are much safer) , plus you get a lot more modern paradigms in the language. Rust can be a little hard to learn in general, but for C/C++ developers it is not a huge step. Hence, my recommendation to use Rust over C/C++ in general, but I only mentioned Gnome here since GTK probably have great Rust bindings due to gnome devs using it.

[You-]

Indeed both CentOS and Gnome are overwhelming Red Hat 'open' projects, and we all saw what Red Hat recently did to CentOS.

Repositioned it to receive tested updates immediately instead of waiting 6 months?

Red Hat Haters are going to hate, but in the Linux land, if you do so, atleast offer an alternative. if you dont like Red Hat funding GTK development, provide or fund your own.

If you look at the charts, the contribution from Red Hat over the past 10 years seems to be fairly constant. It is just that others have reduced their contributions. you cant blame Red hat for that.

There are a few former big contributors that seem to have been assimilated by Google and never heard from again.

Employing a coding machine like Mathias Clasen though, that is just genius. If he ever decided to move, his new employer would massively jump up the contributions charts.

On the other hand, this also shows the lie to the previous argument "Red Hat does not care for the Desktop" and to use alternatives if you really wanted the desktop to succeed. It seems the haters werent only over egging it, but totally wrong. Red Hat's commitmant has remained steady while other "champions" have fallen to the side.

[calc]

It does make me question the future of native applications on Linux, though. It takes a single manager to fire a few people, or they can leave by themselves, to derail the entire development and support of gtk/gnome. For the time being, red hat seems confident in Linux as an enterprise "desktop platform", but the way they've been moving toward Linux on the server and the cloud, I wonder if the end of gtk/gnome is near.

Indeed both CentOS and Gnome are overwhelming Red Hat 'open' projects, and we all saw what Red Hat recently did to CentOS.

[Danielsan]

Yes. DebianXfce will return from the dead to oversee GTK4 adoption and restart his campaign for Xfce world dominance. In fact, rumor has it that he already started GTK5 adoption!

Coincidentally Debian plus XFCE is my daily driver combo... So I am not disturbing about the XFCE world dominance, for instance now we even have a dock plugin for the panel!

[oleid]

it's unclear how retardedness of api makes providing abi easier and writing programs harder. care to elaborate?
last language picking up steam in gnome was vala

Well, I wouldn't call that picking up steam. vala's tooling was always bad. IDE support non-existent.