You can choose a session in cosmic-greeter through a dropdown.

You don’t have to watch. You can listen to it in the background.

It’s really easy to configure a self-hosted forgejo instance. Even if you rm your local work, you can clone it from your server. Be that hosted on the same system over localhost, or on another system in your network.

3D acceleration is required with cosmic-comp right now. I’m not sure if software rendering will be ready or not for the first release, but it is on the issue board.

There’s already been explanations in every thread on COSMIC for the last 2 years. Along with a dozen interviews and conference talks. Why are you demanding answers here?

See the Ubuntu Summit 2024 talk: https://www.youtube.com/watch?v=bwrBKccfYws

It’s not resources, in fact, this Alpha performs pretty poorly on its own vs Gnome

I haven’t seen any benchmark where GNOME was more performant than COSMIC. Despite alpha status, it is already much more responsive than GNOME.

GNOME uses a single thread to render all displays in a multi-display configuration. This is often so slow that they need to rely on double or even triple buffering when the frame rate lags behind the display’s refresh rate. Meanwhile in COSMIC, thanks to the thread safety features of Rust, it was easy to implement thread-per-display multi-threaded rendering. This means that each display is rendered and composited independently on their own respective threads.

GNOME’s compositor also has an entire JavaScript runtime bundled inside of it, which it uses for drawing interfaces and handling application logic for those interfaces. All within the same process as the compositor, slowing down its event loop. COSMIC instead keeps the compositor process very lean, with all desktop interfaces running in their own isolated processes outside of the compositor via wayland’s layer-shell protocol.

If you can’t see the difference, it’s because you’re not even looking.

It can’t be fixed without forking and rewriting a lot of gnome-shell’s internal logic.

Also, COSMIC is not a rewrite of GNOME. Not even close. It is a completely different architecture, toolkit, language, and design system.

deleted by creator

Doesn’t matter. New compositor: cosmic-comp. Does not share any code with gnome-shell or mutter.

OpenGL is required, even if by software rendering.

No modifications are being done to Qt/KDE theming, and we won’t be able to get KDE apps to adapt to the COSMIC theme until the KDE ecosystem has finished migrations to the Union theme engine.

I don’t know how you can keep telling me that I never contacted Canonical even though I did. Nor did anyone ever publicly mock Canonical. You are putting words in our mouths. So much contradictory and hyperbolic nonsense here. Let me guess: you read a certain hyperbolic hit piece from a Chris Davis—one of the most prominent libadwaita and stopthemingmyapp developers—whom had a personal axe to grind with us because of many heated online arguments with him over the petition, theming, and libadwaita. He created a hit piece to influence public perception of the company and intentionally used the GNOME blog to reach the widest audience for his vendetta. Even though if you dig through the details his statements are weak, if not outright false. To make matters worse, GNOME never addressed that personal blog post hosted on their website, even though we had been sponsoring and sometimes hosting GNOME events for 5 years prior, and donated a total of $100K. Leading many to conclude that this was the voice of GNOME, even if internally it was not. This is what happens if you only read the story from one side without putting equal weight on the other.

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.

The alpha began in August of last year, and will continue to be classified as alpha until all features are finished.

The alpha began in August of last year, and will continue to be classified as alpha until all features are finished.

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.