System76's Pop!_OS COSMIC Desktop To Make Use Of Iced Rust Toolkit Rather Than GTK

[mmstick]

I built a couple of the iced example apps to check, and it doesn't render fonts correctly either. However, unlike GTK there's probably not an ideological opposition to correct rendering on desktops and budget laptops, and they'd probably be more welcoming of external contribution than the GTK people are.

We're actually working on improving that right now, along with adding multi-line text support. We have a prototype that's using rustybuzz for text shaping and rusttype for rendering. Work is also being done on locating fonts to cache and fall back on when the default font is missing glyphs. This work will be upstreamed once it's complete.

[yump]

I built a couple of the iced example apps to check, and it doesn't render fonts correctly either. However, unlike GTK there's probably not an ideological opposition to correct rendering on desktops and budget laptops, and they'd probably be more welcoming of external contribution than the GTK people are.

[arQon]

There are already too many toolkits and even the ones that are available have no concept of backward compatibility.

GTK has been co-opted by gnome to the point that it's not a viable toolkit for anyone else to use. Even if anyone did, it has dozens of significant regressions that are being ignored because they don't impact the gnome DE; hundreds of others - like not even handling basic font rendering correctly - being ignored even though they do; and the code is absolutely garbage-tier.

"Open" Qt trails "Real" Qt by a year. That's a very long time when you're dealing with, say, a display server that's still missing key functionality after 15 years, and as a result is constantly having pieces hacked onto the side of it to make up for oversights, mistakes, and hubris.

Everything else is an also-ran.

That adds up to approximately zero usable toolkits, which I'd say is a long way from "too many". So S76 doesn't really have a choice, other than going with "Real" Qt, and they obviously feel like they have good reasons not to do that.
IDK what those reasons are, but if you're going to write your own DE from scratch anyway, the underlying toolkit doesn't really add much work to the project as a whole.

> I read about Gnome team rewriting their gtk+3 apps to support gtk+4.

You haven't really understood things, I think. It's not about "supporting" GTK4, it's about ensuring that programs stop working on GTK3. Especially NON-gnome ones. You can't persuade other people to jump off that cliff if you're not doing it yourself.

[ClosedSource]

I explained in my first response that we have:

- CGlue, a high level framework for Rust-to-C that can carry data as trait objects: https://docs.rs/cglue/latest/cglue/
- Rust-to-Rust compatibility with abi_stable: https://docs.rs/abi_stable/latest/abi_stable/
- Rust-to-C++ and C++-to-Rust with Google's CXX project: https://cxx.rs/
- Rust-to-C binding generator cbindgen: https://github.com/eqrion/cbindgen

Additionally, see the FFI section of the Rustonomicon: https://doc.rust-lang.org/nomicon/ff...st-code-from-c

The Nala team is creating libapt bindings for Rust using CXX with great success. I have used cbindgen for small libraries with basic requirements. CGlue is a must if you want to pass and use more complex Rust types based on traits safely across FFI boundaries. CGlue is possible to use safely with Rust libraries built from a different version of the compiler thanks to abi_stable. abi_stable essentially defines some standard abstractions for distilling Rust into a C API that the consumer can reconstruct back to Rust.

FYI, we use a custom proprietary desktop environment that is written from scratch. However, we do use some open source components such as Qt, GIO from GLib, and others.
Our SOP is integration of features as they are deemed stable. For example, we still don't use pipewire and still only pulseaudio. Any open source packages will have pipewire disabled or rewriting parts till we deem pipewire stable enough. This avoids staying on older versions of software.
We only recently started enabling Vulkan support.
Enabling Wayland will likely happen by the end of 2024 but we're not sure yet.
So instead of rolling updated packages, we roll updated feature sets. We feel this brings us closer to how Microsoft operated with Windows 10 development.

The same procedure happens with hardware upgrades, structure elements of buildings, and mechanical equipment. New construction does not happen without environmental and feasibility studies. It does not commence till any foreseeable impact has been identified and mitigation is integrated into work plans.

[capnbfg]

You're actually ridiculous. Not only is GNOME THE most used DE out there, but if you hold a vanilla Gnome 42 next to Pops horrible Cosmic theme, you see that the Cosmic theme just looks like it has been stuck for a decade, while Gnome simply looks nice and clean. Just because you don't like it doesn't mean everybody hates it. That's just you and a very vocal, yet very small minority. And the few apps already using libadwaita look just way more modern and clean than anything else. So just get over your ridiculous ego.

Do you have any data to back up these opinions? I've been searching for any reputable source attesting to relative market share among the various DEs and so far have come up empty handed. The best I can find are vague claims like "one of the most popular" or "arguably the most popular". In other words "this is my opinion but I have no proof". If you have some data to share, I'd love to see it.

I don't doubt that Gnome has a lot of installs due to which distros include it as the default, but I do question how many users actually like Gnome or stick with Gnome when given a choice.

Anecdotally, here's what I have seen.

I'm an EE at a large tech company. Our company issued laptops run Windows, but for security reasons all development work is done inside a CentOS VM on a remote server. When the transition from Gnome2 to Gnome3 happened a couple years ago, the complaints were overwhelming and many users switched to KDE since it was the only other choice we were given. About 6 months later IT forced all the remaining Gnome users over to MATE and disabled Gnome altogether, due to the sheer volume of complaints they were getting.

Prior to this job I worked at a startup company (only 20 people at our local office), where engineering was my primary role and IT was my secondary role. I personally hand-built most of the machines in our compute cluster. All were running CentOS. When we upgraded to CentOS 7 I anticipated the backlash and prepped all the desktop workstations with KDE, MATE, and Gnome3 Classic. Disk space was no concern, so why not offer the users interactive selection of their DE? One user was a die hard KDE fan who predictably chose that. Another user gave Gnome a serious try, but after about a week he gave up and switched to MATE. The rest quickly chose MATE.

I know a few people who use Linux at home, I know far more people who use Linux professionally, and I cannot name a single person who prefers Gnome3. Personally, I tried it long ago and quickly moved on. I've also experimented with KDE, LXDE, MATE, and Cinnamon. These days I'm mainly an XFCE user. Our home NAS runs openSUSE with LXDE, but that is the exception. My primary desktop PC, our backup server, our TV PC, our laptop, and my daughter's netbook all run Xubuntu. Recently my wife switched from Windows 10 to Kubuntu. I haven't used that enough yet to decide whether I like it better than Xubuntu, but I can already confidently say that it's better for me than Gnome.

I've seen articles and reviews about System76 hardware and Pop!_OS, and I conceptually I love what they're doing. But frankly, the only reason I haven't experimented with Pop!_OS is because the default DE is Gnome. I'm really interested to see what they do for their own DE.

[Artim]

I never found Debian or Debian derivatives to be beginner friendly. All their guides either show users how to use the terminal or add third party repositories. Pop!_OS from what I’ve seen is great to deploy professional environments within minutes but with containers I can do that on practically any distribution.

I found Solus to be the best beginner friendly operating system once it’s actually installed. Almost all their guides include the GUI and the terminal alternative. Wish they had a bit more support due to a few missing packages in their Software Center but the packages missing I can get them from Flatpak.

I don’t see a need for Windows aside from gaming since I enjoy HDR and a few titles that’s anti cheat engines don’t work on Linux.

I support System76 and the Budgie team in using an alternative Toolkit.

Well I don't need a beginner friendly distro, rather one that works. I just heard all the praise it has gotten and Debian itself is just a bit too conservative for me, even on testing. Ubuntu obviously was out of the question because of their desperate need to become as user-unfriendly as possible, so I thought in Pop I would find a great distro with much less work involved to get it into great shape. Well that was a bust, I almost guaranteed had less work with plain old Debian. But the hunt for the perfect distro is something for a whole other thread and platform.

[WannaBeOCer]

LOL. And that's "catering to beginners" for y'all. If you want any support when you really need help, just use Windows. In the end we don't do anything better than them.

I never found Debian or Debian derivatives to be beginner friendly. All their guides either show users how to use the terminal or add third party repositories. Pop!_OS from what I’ve seen is great to deploy professional environments within minutes but with containers I can do that on practically any distribution.

I found Solus to be the best beginner friendly operating system once it’s actually installed. Almost all their guides include the GUI and the terminal alternative. Wish they had a bit more support due to a few missing packages in their Software Center but the packages missing I can get them from Flatpak.

I don’t see a need for Windows aside from gaming since I enjoy HDR and a few titles that’s anti cheat engines don’t work on Linux.

I support System76 and the Budgie team in using an alternative Toolkit.

[Artim]

Nobody has time to respond to every support request on GitHub. In general, if you want guaranteed support, you have to pay for that.

LOL. And that's "catering to beginners" for y'all. If you want any support when you really need help, just use Windows. In the end we don't do anything better than them.

[ClosedSource]

I explained in my first response that we have:

- CGlue, a high level framework for Rust-to-C that can carry data as trait objects: https://docs.rs/cglue/latest/cglue/
- Rust-to-Rust compatibility with abi_stable: https://docs.rs/abi_stable/latest/abi_stable/
- Rust-to-C++ and C++-to-Rust with Google's CXX project: https://cxx.rs/
- Rust-to-C binding generator cbindgen: https://github.com/eqrion/cbindgen

Additionally, see the FFI section of the Rustonomicon: https://doc.rust-lang.org/nomicon/ff...st-code-from-c

The Nala team is creating libapt bindings for Rust using CXX with great success. I have used cbindgen for small libraries with basic requirements. CGlue is a must if you want to pass and use more complex Rust types based on traits safely across FFI boundaries. CGlue is possible to use safely with Rust libraries built from a different version of the compiler thanks to abi_stable. abi_stable essentially defines some standard abstractions for distilling Rust into a C API that the consumer can reconstruct back to Rust.

thanks. That addresses my concerns

[Danielsan]

The only good news here is the ICEwm 3 was released so we can toss both Cosmic & Gnome3+N...