What makes you think I’m “salty”? I’m not the one complaining about NVIDIA not working in Wayland, or saying that I’m going to sell my GPU.

The only person who is salty is the one who would rather sell their GPU than use a Wayland desktop environment that supports NVIDIA as a first class citizen.

Then have fun with your bad experience. NVIDIA is working quite well in Wayland on COSMIC.

Try out COSMIC with the NVIDIA 550 beta driver.

It already supports VRR and DRM leasing. VRR monitors and VR headsets have been tested.

Translation: no one should ever attempt to innovate on the Linux desktop. GNOME is the epitome of software development and everyone else should quietly give up. If GNOME can’t fix an issue, no one can. Only GNOME has the god-given right to make decisions on how desktops are developed for Linux. There can only be one party. The One Desktop principle. Contribute to your party leader, or else…

We will be adding integrations to our theme engine to automatically generate themes for GTK3, GTK4, and libadwaita.

The GTK4 project was cancelled for multiple reasons. We originally began working on Relm4 to use GTK4 for COSMIC applets. While others on the team were also experimenting with alternative Rust GUI libraries.

It required a lot of effort to patch GTK4 to support the Wayland layer shell protocol. Getting those patches merged into GTK4 was also taking a much longer time. There were long delays between code reviews; and they also wanted a series of much larger refactoring changes to be made to GTK4 before exposing the layer shell feature. It was much easier to get layer-shell working with iced, as it is a much leaner and concise code base.

GTK does not support fractional scaling, which is something we want our applets to support on day one. This was one of our major concerns. A concern that didn’t apply to iced.

It was also exceedingly difficult to create custom widgets with GTK in Rust. Even those of us with years of experience considered it to be unreasonably difficult. So it was not feasible to expect new hires on the team to be able to comfortably develop COSMIC components with it. In comparison, our team was able to develop custom widgets with iced with much less effort and with greater flexibility, so the demand for iced grew stronger.

At the end of the day, GTK is not a Rust toolkit, and its API is cumbersome to adapt to Rust. Use of GTK would always be a compromise that lessens the developer experience for COSMIC app and applet development. A compromise that would eventually require us to rewrite everything in a native Rust GUI library the moment it would become possible to do so.

Since we are developing a desktop environment from the ground up anyway, we decided that there would be much more value for our time if we contribute to the Rust ecosystem and utilize iced to make a fully featured GUI library for application development.

It would certainly be easier for them to port COSMIC because there are very few dependencies on shared C libraries. Cargo links all Rust libraries statically, so it’s easier to maintain and update components. This will depend how open they are to accepting Cargo and Rust into their ecosystems.

The keyword is alternative. All first party applications are written natively with our libcosmic toolkit, which is based on iced-rs. We are using a fork of iced though because we needed to implement a custom runtime with the sctk (smithay client toolkit) for COSMIC applet development, but our desktop applications will use the original winit runtime.

As long as you have access to the latest version of Rust, porting would be somewhere near cowsay.

That would compromise our vision of a GUI platform built from the ground up in Rust. It would also not be feasible to use Flutter for applet development. We can easily make modifications directly to iced for all the Wayland integrations that we need in COSMIC, as the iced code base is very lean, and written in Rust.

We are integrating AccessKit into libcosmic for accessibility support.

If you want to develop applets and/or applications with libcosmic, you must do so with Rust. There are no plans to develop C bindings for libcosmic.

COSMIC is being written in libcosmic, which is based on iced.

I don’t think you can say that because we haven’t published our design language yet. Only a handful of design mockups have been published so far. The screenshots here are not design mockups but a work in progress implementation. Hence the “In-progress” part of the title.

Rounded corners are a user preference in the Appearance page in COSMIC Settings.

Corner roundedness is personal preference in the Appearance page in COSMIC Settings. Similar to interface density.

As of today, https://pop-os.github.io/libcosmic/cosmic/ is now available.

Sounds like voltage droop and/or a motherboard with faulty automatic “training” settings. I don’t recall if the Ryzen 3000 had custom PBO curves, but tweaking this can fix it. Upping LLC and the SOC and CPU voltage slightly alternatively could help. Though I’ve had my most stable overclock by disabling PBO entirely and using a manual CPU multiplier.

You can generate documentation by running cargo doc and browsing the generated web pages in target/doc. There are also examples in the examples directory of libcosmic, as well as a design demo example which is a WIP.

libcosmic is an alternative toolkit for building desktop applications and layer shell applets. It wouldn’t make much sense to build a toolkit only for ourselves. It’s the best way to develop layer shell applets for COSMIC, and other Wayland compositors that support the layer shell protocol.

It’s difficult to say for sure with certainty what the issue is without trial and error. I would expect that the motherboard’s manufacturer would make sure that their board can successfully pass all tests with the standard JEDEC spec for DDR4 (2133 MHz).

Since you say that you’ve tried different RAM kits, another alternative could be the cleanliness of power from the power supply. Perhaps there is intermittent voltage droop, and you need to experiment with the Load Line Calibration settings to adjust for vdroop between idle and load. Disabling frequency boosting and manually setting the CPU frequency could help check if it’s related to that. PBO curves might be undervolting too much while idle.

That’s already not possible on GNOME because some GNOME applications hardcode their theme, others use libadwaita, some use GTK4 without libadwaita, some use GTK3, and there may still be a GTK2 app lingering around here and there in the repos (ie: GIMP).

Few people are going to care that there’s a GTK application installed on their COSMIC desktop. COSMIC will automatically generate GTK3/4 themes to match the system theme. We may even automatically generate a libadwaita theme, so it will look “same enough”.