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 10 years. 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.
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.
Alpha 5 is actually releasing next week. I'd also disagree with "very alpha" as most of the beta milestone is finished now. Regardless, I don't understand where the disconnect is. A spin can release at any time. Doesn't matter when COSMIC Epoch 1 releases.
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.