What report are you referring to?

What GPU configuration do you have? I don’t have any of these issues. If NVIDIA, you have to wait for NVIDIA to release explicit sync Wayland drivers.

What makes you think I’m “salty”? I’m not the one complaining about NVIDIA not working in Wayland, or saying that I’m going to sell my GPU.

The only person who is salty is the one who would rather sell their GPU than use a Wayland desktop environment that supports NVIDIA as a first class citizen.

Then have fun with your bad experience. NVIDIA is working quite well in Wayland on COSMIC.

Try out COSMIC with the NVIDIA 550 beta driver.

It already supports VRR and DRM leasing. VRR monitors and VR headsets have been tested.

Translation: no one should ever attempt to innovate on the Linux desktop. GNOME is the epitome of software development and everyone else should quietly give up. If GNOME can’t fix an issue, no one can. Only GNOME has the god-given right to make decisions on how desktops are developed for Linux. There can only be one party. The One Desktop principle. Contribute to your party leader, or else…

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.

GNOME was focusing on building Rust bindings for GTK for many years before Qt development picked up. The GTK bindings were usable within a year or two after Rust’s 1.0 release. Yet even today, those looking to build applications in Rust will find that GTK is the only mature toolkit right now. And if you’re doing that today, I’d recommend starting with Relm4 for the best GTK Rust experience.

Rust does not support the C++ ABI, and Qt does not provide a C interface, so much work has to be done on building the tooling for binding C++ libraries to Rust. That work is still ongoing, so some have opted to use QML instead of interfacing with Qt C++ libraries. Yet if you’re looking to use Qt or QML, you may as well use Slint instead. It’s developed by former Qt/Trolltech developers and has a similar approach as QML.

You don’t seem to realize that this is equivalent to that. The user already made the choice to install a desktop environment which generates themes. So if you make the choice to build an application with GTK, and you want users to be able to use system themes with it, then consider it done.

To argue otherwise would make you a hypocrite. It would mean that you don’t actually want users to use themes, so you take issue with desktop environments which make it easy to do so by default. So if you want people to be able to use themes, then you shouldn’t complain when people choose to use a desktop which enables that use case.

You’re so silly. If the developer doesn’t want a themeable application, then either don’t use a themeable toolkit, or hardcode the theme so that the system theme is ignored.

Yes, this can already be seen when configuring a personal theme in the Desktop > Appearances page in COSMIC Settings. Compositor elements, applets, the login and lock screens, and COSMIC applications automatically adjust in realtime to the configuration changes.

Yes, the libcosmic toolkit automates a decent chunk of the process to building an application with our interface guidelines. If building an application with the cosmic::Application trait. Which includes the header bar, navigation bar, and context drawer.

We will attempt to automatically generate themes for common toolkits, but the desktop environment has no control over how the toolkit chooses to render itself or operate.

It uses a custom UI framework, St, using referring primitives built into the compositor, mutter. Whereas COSMIC is using the same libcosmic library inside the compositor, applets, and desktop applications. Thanks due to our Smithay client toolkit being used to provide a renderer for iced which supports the Wayland layer shell protocol.

The next Pop!_OS release will use COSMIC as its desktop environment instead of GNOME. There will be an upgrade path, same as in previous releases.

Depends on what you are wanting to configure. To configure displays, use wdisplay. I personally use the system defaults.

Since around June/July.

The cosmic-greeter package is already installable today. It will work on any system that has greetd available. The Appearance panel in COSMIC Settings is not yet merged, but it is in the appearance staging branch.

The desktop environment doesn’t control how applications look or function. Regarding theming, GTK3 applications need a GTK3 theme, GTK4 applications need a GTK4 theme, libadwaita applications need a libadwaita theme, and KDE applications need a KDE theme. Our tooling for generating themes will attempt to generate themes for other toolkits, but COSMIC applications have a different design language than GNOME or KDE applications.