COSMIC: The Road to Alpha
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".
Iced is a lower level GUI library, similar to what GDK is to GTK. We built our own COSMIC-themed GUI toolkit around iced, which is called libcosmic. As we've gotten more and more widgets and application logic developed, actual application development with libcosmic is a breeze. Even if you do have to create a custom widget, it's much easier to creating custom widgets in GTK. We're able to develop much faster than we ever could with GTK now.
Yew and Leptos aren't comparable since they're not native GUI toolkits. These are for web developers rather than application development. It wouldn't be possible to use this for developing layer shell applets for COSMIC, either.
It's been explained 100 times ad nauseam over the last two years. Go read comments from previous months' updates if you want to catch up.
As for cross-platform compatibility, this should not come as a surprise because everything is written in Rust, and the libraries we use are already cross-platform by default in most instances. Supporting multiple platforms takes almost zero effort on our part. Especially when we could design something from the ground up that's easy to adapt.
None of what you stated makes sense. Most people are not using exclusively GNOME applications on GNOME, or exclusively KDE applications on KDE. Like with elementary OS, most people are running applications like Steam, Spotify, Discord, Zoom, Slack, etc. Plenty of people are using Qt and KDE applications on GNOME, or GTK and GNOME applications on KDE. You think no one uses Krita or Scribus on GNOME, or GIMP on KDE?
Thanks to Flatpak, you might even be running elementary applications on your system. Even Windows back in the late 90s and 2000s was full of desktop applications with custom proprietary interfaces. Nowadays everything's becoming a web view bundled with a Chromium runtime, and you're more worried about a COSMIC app ecosystem having a different UI from GTK?
COSMIC is a good thing because it's a standardized and open source cross-platform native desktop toolkit. People can create themes for it, and those themes can be bundled alongside GTK and Qt/KDE themes. Due to the nature of how Rust libraries are developed and linked, COSMIC applications are mostly statically-linked, which even makes it trivial to put them on a USB drive and bring them to any PC.
I'm not sure why you think this is unique to COSMIC or elementary OS. Do you not realize that this is true of all operating systems? Look at Steam, Spotify, Discord, Zoom, and Slack for starters.
Make sure you have the latest firmware for your motherboard. This sounds like unstable voltages for memory, or an overly-aggressive PBO curve. Did you try disabling the XMP profile on the RAM, disabling PBO, and upping the voltages (within safe limits) of the SOC, DDR, and VDDP? You might find some useful info here[0] or here[1] if you intend to run your memory at 3200 MHz.
If they support the wlr output configuration protocols, then yes it'll work fine. There are some more advanced features that we want that aren't supported by the protocol though, so we will likely develop some cosmic protocol extensions for those features.
Let him do his thing and investigate Pop on your own.
Because that's not how software development works, and that's not how you make progress in the field. In order for our technical vision to be integrated with an existing desktop, such as GNOME, it would have required that they give us the reigns to their project to delete their entire codebase and rebuild it into exactly what you see today in COSMIC.
As in life, sometimes you've got to demolish, pave, and build better foundations. There's a lot of cool technologies available to build a truly next-generation desktop experience in, but you're not going to get it through rigid bureaucracy and old tools. With COSMIC, we've got freedom to make decisions and build something truly unique, and we're using our talent to show you what we can do.
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.