It is normal for cosmic applications to write logs to the terminal.

You have to type the key sym name into the input field. It is not a raw shortcut editor yet.

You are already on the LTS version if you’ve installed the COSMIC Alpha 6 ISO, or did a release upgrade.

You can’t release a desktop operating system without a file manager or text editor. The xdg desktop portal interface for the file chooser portal dialogs requires a file manager to be implemented for the portal to be able to create a file chooser dialog for the operating system on behalf of applications requested file choosers through the portal.

The text editor is also required to have a GUI toolkit featuring properly rendered and editable text. It is thanks to the text editor project that the Rust ecosystem now has cosmic-text as the de facto crate for handling text layout, shaping, and rendering with support for international language glyps, ligatured language scripts, and bidirectional text layouts.

Virtual machines have always been supported as long as you enable GPU acceleration. GNOME Boxes, virt-manager, and VirtualBox have been tested.

Your link demonstrates the exact opposite. GNOME rejected a patch for disabling mouse acceleration profiles, and I then ported that patch to Pop!_OS. It was often the case that I merged third party patches into Pop!_OS that were either rejected by GNOME, or were in an actively-open PR. In all instances where contributions could be upstreamed that we worked on personally, pull requests were given to the appropriate projects. And it is the case that many such instances were merged into GNOME, such as the keyboard settings page redesign. Our team has submitted many contributions to GTK, GNOME, and other projects over the years, so to smear us for not contributing upstream is incredibly deceitful.

Issues with youtube-dl being outdated are constantly reported on Launchpad, and are still an issue to this day because YouTube keeps changing the API. It was reported at that time as well. In fact, I have submitted several patches upstream to Ubuntu through Launchpad over the years, but unfortunately they typically go straight into limbo because developers rarely notice them, and it’s difficult to get their attention. It’s usually better to go straight to the upstream developer to get those changes merged there, and therefore the issue will be fixed in the next release of Ubuntu when they package the updated software. If Canonical is interested in any of the work we have done in Pop!_OS, they are also free to take from our GitHub repositories. It’s all open source, after all.

It speaks to me that you have certain intentions and motivations in your speech to paper over the good we’ve done over the years to focus on small nit picks. Nitpicking an obscure debian changelog that no one reads and was never presented to the user is a very poor argument. I was frustrated at the time because youtube-dl kept breaking and we kept getting issue reports on it. I was unable to get any response from Canonical, so I fixed it myself in Pop. I haven’t written anything in the debian changelog fields since then.

This is the actual truth of the matter. COSMIC is the result of many years of planning and developments in response to customer requests in Pop!_OS. Over time, the COSMIC extensions for GNOME diverged in UX to the point where it was untenable to maintain long-term, and impossible to make further progress without forking. We were going to create a modern desktop environment in Rust from the ground up regardless of whether disputes happened with GNOME Foundation / Core members, even if disagreements helped to accelerate that goal.

Today we have built a highly modular desktop environment in Rust from the ground up that anyone can use as a platform for building an operating system with thanks to the flexibility of the Wayland layer-shell protocol. You may mix and match any arrangement of layer-shell applets in any order. You can even swap out the cosmic session for a different desktop environment’s session, and vice versa load another desktop environment’s session inside of cosmic-comp.

Distribution and user theming is also significantly improved over GTK with programmatic generation of themes—automatically adapting colors at runtime to the most ideal contrasting color values via OKLCH and other related algorithms—which distributions can use to customize to their preferred branding, and app developers can freely adopt without needing to worry about user themes breaking their apps. Users also get the convenience of generating their own custom themes with COSMIC Settings, even if that means creating an abomination of conflicting colors.

We really wanted to improve upon the developer UX for Rust GUIs by creating libcosmic, and have succeeding in doing so with a toolkit based on Iced that uses Elm’s Model-View-Update paradigm. It is so much easier to build apps and applets with libcosmic compared to gtk4-rs. I have a lot of testimonials from developers who have built apps and applets with it. Some of which have also contributed a lot to cosmic and libcosmic, even if they had little or no Rust/programming experience previously.

Also, while it may be alpha, it is very usable. It is only in alpha so long as all features aren’t implemented yet. You may have to supplement a GNOME app here or there. Some bugs are also expected, but it works great otherwise. In many ways better than the 22.04 environment currently offered.

That’s honestly a very revisionist version of history. Unfortunately I’m too tired to do a proper rebuttal to it. We have made many upstream contributions to GNOME. There has never been an instance of refusal to upstream anything. There has been instances of upstream not being interested in our contributions though. But that’s how things go when you have creative differences with an upstream, or have technical contributions which aren’t of interest to upstream’s use cases. Keep in mind that just because a downstream makes something cool and interesting, it doesn’t automatically mean that creation fits in with upstream’s vision for their project. Hence why there’s hundreds of gnome-shell extensions that aren’t built into GNOME.

There is a whole team working on COSMIC. Paid, full-time developers, UX designers, and a QA team.

Give it a try. We are close to being finished. I don’t even know why anyone would think this isn’t a thing.

That just depends on your use case. I’d imagine you’d only get 5-15% performance difference. Choice of programming language and the quality of the code makes a bigger impact on performance. Case in point, Rust’s png library is 1.8x faster than the C libpng system library. Of course, only Rust applications benefit from that, unless the C libpng maintainers decide to adopt Rust’s png library as their implementation.

Not ready to release yet

Wayland compositors use IPC over a UNIX socket to communicate with Wayland clients. To increase security and enable sandboxed applet support, COSMIC applets use the security-context protocol for their IPC connection to the compositor. To be an applet, COSMIC applications use the layer-shell protocol to behave as an applet. Neither of which were made for COSMIC. Some other Wayland compositors support these protocols. You can see which compositors support the protocols at the bottom of the wayland.app protocol pages.

In practice, because Rust libraries are always statically-linked, the MPL-2.0 is equivalent to the LGPL in spirit. Meanwhile, because of the static linking restrictions in the LGPL, the LGPL is effectively no different from the GPL. Hence, you’re going to find a lot of open source copyleft projects from the Rust ecosystem preferring either GPL or MPL-2.0, where MPL-2.0 is used in libraries where LGPL would have used previously in C projects. Dynamic linking is essentially going the way of the Dodo.

The Linux kernel already allows proprietary modules via DKMS, and a handful of vendors have been using this for decades, so this is no different. Case in point: NVIDIA driver, and Android vendor drivers.

All source code in Rust is statically-linked when compiled, which thereby renders the LGPL no different from the GPL in practice. For Rust, the MPL-2.0 is a better license because it does not have the linking restriction.

Niri is also based on the smithay library we use for COSMIC, so there’s some collaborative work between COSMIC and Niri on Smithay.

applets live in their own process and communicate via Wayland protocols (behind a COSMIC API)

Even better. A COSMIC API was not necessary since Wayland protocols already exist for this (layer-shell and security-context).

It already is available. See the links on the COSMIC webpage: https://system76.com/cosmic

No, we won’t be spending any development time on porting all of the patches in 22.04 to 24.04. GNOME is done.