I’m a System76 engineer / Pop!_OS maintainer. I’ve been a Linux user since 2007; and Rust since 2015. I’m currently working on COSMIC-related projects.
Development began mid-December, using the work we already did for cosmic-edit as a template. COSMIC Terminal uses the alacritty library, but the frontend interface is designed with our platform toolkit (libcosmic), with full support for bidrectional text and ligatures because we use cosmic-text instead of freetype.
You can see above that between alacritty, cosmic-terminal, and gnome-terminal; cosmic-terminal was the only terminal to render correctly. Since then, we’ve given it the COSMIC treatment and now we have a tabbed interface with settings, search, etc.
No, we have been making our own platform toolkit (libcosmic), which is built upon iced-rs. We are using this both for our wayland compositor applets, and our desktop applications.
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.
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.
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.
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.
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.
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”.
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.
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.
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.
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.
COSMIC is a Wayland desktop environment for Linux that is written in Rust with Smithay and Iced. COSMIC applications are developed with the libcosmic platform toolkit, which is based on iced. They are cross-platform and supported on Windows, Mac, and Redox OS in addition to Linux....
We’ve been using COSMIC on our systems since summer of last year. Some graphics drivers have issues, particularly NVIDIA drivers using Vulkan on Wayland. There are some XWayland bugs from time to time. It is very usable as is, but some settings aren’t implemented yet, and some toolkit features aren’t fully implemented.
NVIDIA believes they’ll have the Vulkan on Wayland issue fixed in the 550 driver that they are planning to release early this year. Someone’s working on a fix in wgpu that happens to also boost performance for every driver in demos.
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.
<span style="color:#323232;">Me: Can we have COSMIC?
</span><span style="color:#323232;">Mom: We have COSMIC at home.
</span><span style="color:#323232;">COSMIC at home: Attempting to call back into JSAPI during the sweeping phase of GC. Stack trace for context
</span>
Joking aside, COSMIC is nothing like GNOME. Not visually, not feature-wise, nor is it using the same software stack. It is as close to GNOME as KDE is to GNOME. Developed from the ground up in Rust.
They commented on their video that it was their fault. There was never a packaging issue. The issue was that we pushed a systemd source package update to Launchpad, which silently didn’t build or publish the 32-bit systemd library packages, because Ubuntu had systemd on a blacklist for 32-bit package builds. We noticed this minutes after packages were published, and had it fixed within an hour later.
This didn’t actually affect any systems in the wild because apt held back the update until we had worked around the restriction on Launchpad (there was an invisible ceiling to the package version number). They were only affected during that time period because they manually entered that sentence from the prompt in a terminal. We stopped using Launchpad with 21.10, so all packages released since then are the same packages that are built and tested by our packaging server, and used by our QA team internally.
The drama and reputational damage that LTT caused was unnecessary. Especially given that they uploaded this video a week later, and never attempted to reach out. They still have yet to properly edit the video.
COSMIC DE: The Road to Alpha (blog.system76.com)
cross-posted from: programming.dev/post/8455606...
Random application segfaults on Arch
Hi everyone,...
Pop!_OS Cosmic Desktop Updates - Cosmic Terminal, Files, and More (lemmy.world)
Reviewing some of the latest updates with the cosmic terminal, files, and more.
In-progress COSMIC apps: terminal, file manager, text editor, and settings (fosstodon.org)
COSMIC is a Wayland desktop environment for Linux that is written in Rust with Smithay and Iced. COSMIC applications are developed with the libcosmic platform toolkit, which is based on iced. They are cross-platform and supported on Windows, Mac, and Redox OS in addition to Linux....
Linux Distros Evolution - January 2024 Update: Pop!_OS in Decline? (boilingsteam.com)
An interesting trend graph of the most diffused distros and their adoption by users over time.