GTK 4.0 Toolkit Officially Released

[hsci]

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!

Haha

Geeqie is finally approaching Gtk3. And maybe we will see Gimp on Gtk3 soon, too.
I'm still suprised, that MySQL-Workbenach and LibreOffice were faster.

[pal666]

It's a feature imho. Qt API uses jest the right, minimal subset of C++. Would you really prefer std::function and std::bind clutter instead of connect and slots?

i would prefer signal support in c++ like several real c++ libraries do, instead of moc language. i would prefer not seeing pointers sticking out of every hole. i would prefer standard types instead of qt-only bullshit. i'm sure there would be much more things i prefer if i used qt

Would that really make it more readable and easier to use?

yes. for c++ programmers that is(qt programmers aren't c++ programmers)

Out of curiosity, do you consider boost as good example of C++ library?

yes. and it can implement signals in c++

[pal666]

Rust will make sure that you don't accidentally share references across threads. And thus, racy reference dangling will simply not happen.

that's not the only kind of errors in multithreaded programs, so rust will not make your threading bugfree

The prime pattern for multi-threading in rust is message passing.

you can use such pattern in c++ if it suits your application

Maybe, but it is THE example for a c++ based GUI toolkit.

"based" only matters for its developers. for users gtkmm is much better example

[pal666]

Not for a GUI library its not (at least if you don't want the API to be retarded).

it's unclear how retardedness of api makes providing abi easier and writing programs harder. care to elaborate?

As pointed out elsewhere, Rust is picking up steam in Gnome

last language picking up steam in gnome was vala

[oleid]

that's not the only kind of errors in multithreaded programs, so rust will not make your threading bugfree

True. Nobody said language X would make your programs bug-free. You are free to add all the logic errors you would like.

you can use such pattern in c++ if it suits your application

Keep in mind that sending values around in C++ is not necessarily thread-safe, IF they contain pointers to other data.
Also, std::shared_pointer can easily be mutated from different threads.
Anyway, what libraries can you recommend?

"based" only matters for its developers. for users gtkmm is much better example

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

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

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

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

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

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