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

[mmstick]

That you are grasping for straws is obvious as you do conveniently don't want to get points. The Pop shop was just the most obvious problems, I've listed enough points about what's wrong with it. And no, the first thing to try should always be to manually set the current version in the source files. Only after apt making it clear that that won't be a good idea, then you do a fresh install. That's what's called user friendly. And that you conveniently ignore me talking about less common issues that simply get ignored, was also obvious from the get-go. But obviously I refuse to let that go that easily. I reported months ago about packages being held back and even refusing to update, at quite a few others had. The only answer you have on Reddit was basically "I don't have that problem so I don't give a damn". I also created an issue on the Pop GitHub, as upstream regularly refuses to give any support to anything not under their direct control (in this case, any Ubuntu based distro not being officially supported by Canonical). As you can see, there was not even a try to find the cause of the issue, let alone to fix it. But of course I'm only having an agenda and imagining things. But go ahead, make yourself a complete fool, that's not my problem. Not that your argument of only being able to prove a software shop that works more than just half the time when rewriting everything in Rust isn't doing that already pretty well.

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

[Danielsan]

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

[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

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

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

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.

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

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

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

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