System76's Pop!_OS COSMIC Desktop To Make Use Of Iced Rust Toolkit Rather Than GTK

[Mez']

The funny thing (and proof of how wrong you are) is that current gnome development is not even being lead by Red Hat. They maintain and develop parts of the historical stack, not the new fangled bits.

All the changes you are critical of are lead by non-RedHat employed individual community members, Purism and EndlessFoundation.

Granted they all need the base provided by Red Hat to excel, but Red Hat isnt leading, dictating or often even involved in the discussions.

Probably grossly misrepresenting the number of contributions, but the focus of work for the desktop stack (ignoring lower stack kernel, drivers, systemd where Red Hat is heavily invested) is along the lines of:
Red Hat's work is focused on things like pipewire, (gtk) toolkit, settings, VTE, developing the High Dynamic Range and Colour stack etc.
Purism focuses on libadwaita and the linked app ecosystem.
Endless focuses on the Gnome Shell.
Flatpak and portal development is mostly shared by Endless and Red Hat (and used by Purism).
(Canonical and other companies do stuff across the board without me having a sense of a strong sense of focus on a particular part of the stack)

Red Hat still represents 70% of the contributions.
And Purism, well... They are failing big time with their ridiculously overpriced and lacklustre products. It is obvious from all their interventions and replies that they have a similar arrogant mindset as the one from Gnome. No surprise here if they work together and completely mess up theming on Linux.
App ecosystem of Gnome is total NIH used by 3 persons, while there are at least 5 better, established and well-known apps for each use case they NIH a new one.

You may hate "Red Hat" and its conspiracy but the foundational technologies they work on benefits us all. However their developers have stayed away from the new focus precisely because they have been burnt out by adhominems spread by posts like yours.

I am looking to see where they get with the HDR milestone within the next 6 months.

Their technologies are in general a disservice to all and the community. They are only interested in their developer-oriented user base, but they don't know anything about what the normal end-user wants, because they are bunkered down in the small world of theirs.
And the worst part is that with the means of the bigger Linux company they develop complex enough apps on a technical level that others are discouraged to develop their own similar thing. In the end, it traps everyone into whatever they're going to do with it, which almost always end up to not being very good (exception would be pipewire).
Mutter is such an example, it's very complex on the technical side, and others don't want to start developing a similar juggernaut, but Mutter fails to deliver on about every level and at the same time it traps the user or other DEs into it, like Budgie. I really wish the likes of Budgie, XFCE, Mate or Cinnamon or the Canonical people would work together to counter-balance that monopoly and if they work together they would have a big enough size to come up with a very good alternative that they would be able to control by themselves. And it would most likely be much more focused on the user than Gnome is. Gnome is indeed made by developers for developers, while every good piece of software is driven by users (user requirements) for their end benefit (they will use it).
Maybe Cosmic can drive that effort. They clearly have an open mind, as opposite to Gnome people.
I dream of a Linux ecosystem free of the Red Hat technologies, it might make things hard in the beginning (given the state of the stack) but on the long haul I think it would benefit the Linux community ten-fold.

[Mez']

wayfire does have some neat gimicks, but some things I miss dearly are snapping to the edges when ctrl dragging, and having easy themeing and stuff. but that being said, it's fast, the effects are kinda useful actually, I can have a terminal command on another virtual workspace and just peak at it using the cube effect. and the basics are all there. being based on wlroots, it has the same blood as sway, meaning a lot of the sway related apps work fine too, I can have pretty nice features like mpv-paper for video background, a lot of the wlroots specifc apps work great too.

I tried it a while back and it had an openbox feel to it as you needed to right-click to get a menu as the top bar had nothing in it. Everything was slow to a crawl. It wasn't even alpha software back then (maybe 12-18 months ago, can't remember). It probably has evolved since.

[Mez']

QT apps look like poop. KDE looks dated, and no ammount of skinning fixes that, QT apps look very stiff in general. I honestly do not think QT is capable of good looking and aesthetically pleasing UI IMO

Agreed. That's why even though I despise what Gnome has become, I can't bring myself to even try KDE. Either adwaita or the QT look just don't sit right with me.

[Mez']

Rust was never a meme. It's a real movement that's been happening industry wide. Those calling it a meme have just been hiding their head in the sand while the tidal wave rapidly approaches.

Gnome lovers must really love the sand, they tend to bury their head in it particularly more than others.

[Mez']

This is just rich. Instead of ditiching their ugly Cosmic theme and switch to vanilla Gnome with just a few additions and put work into more urgent stuff like making a software store that actually works (imagine you say you want to cater to absolute beginners, yet your software shop is so riddled with bugs that one can only recommend using the terminal instead or at least Synaptics), instead they literally waste their time building yet another DE with yet another UI toolkit "bEcAuSe It'S rUst!!!!". They get more and more ridiculous by the day.

Nobody wants vanilla Gnome, get over it.

And if Cosmic is ugly, what is adwaita? It's objectively a badly designed amateur theme, and subjectively it's just the most hideous one ever made. I'll take any theme over Adwaita. ANY.

[Artim]

Nobody wants vanilla Gnome, get over it.

And if Cosmic is ugly, what is adwaita? It's objectively a badly designed amateur theme, and subjectively it's just the most hideous one ever made. I'll take any theme over Adwaita. ANY.

You're actually ridiculous. Not only is GNOME THE most used DE out there, but if you hold a vanilla Gnome 42 next to Pops horrible Cosmic theme, you see that the Cosmic theme just looks like it has been stuck for a decade, while Gnome simply looks nice and clean. Just because you don't like it doesn't mean everybody hates it. That's just you and a very vocal, yet very small minority. And the few apps already using libadwaita look just way more modern and clean than anything else. So just get over your ridiculous ego.

[Quackdoc]

Multi-monitor and workspaces will be killer features in COSMIC. Mutter likes to assume that people want all displays to be a part of one large workspace, or to have workspaces only for one display. Neither are valid approaches for most people.

I've tinkered with the cosmic compositor a bit and so far, albeit basic, do like what's there. will it have the ability to choose which GPU it renders on? IE. having a display on GPU A, but being able to select GPU B for rendering?

this is necessary for a few features, but for an example of where this is useful, say you have dual gpus and do gpu passthrough. you can have a single monitor plugged into the host gpu. it would be really nice to be able to elegently remove the gpu from the server (much like eGPU) even if it is the only head, and be able to bring it back up when the gpu comes back (when a passed through gpu is brought back from a VM properly, it acts much in the way a an egpu coming back online).

I suspect as long as cosmic can elegantly handle loosing all of it's displays (I think this is an issue with some people's HDMI monitors too?), handle gpu hotplug (much like eGPU), and rendering on a separate GPU, the pieces should align pretty well for this usecase. since it is more or less a collection of issues people have anyways into one single usecase.

[Quackdoc]

I tried it a while back and it had an openbox feel to it as you needed to right-click to get a menu as the top bar had nothing in it. Everything was slow to a crawl. It wasn't even alpha software back then (maybe 12-18 months ago, can't remember). It probably has evolved since.

it's not too bad now, it's pretty snappy on my rx580

[mmstick]

Another question. that I have on Rust is about libraries. Does everything in rust have to be statically linked? Can a gui library be a shared library?

You can create dynamic libraries in Rust, and there are some libraries that can automate this at a high level for Rust-to-Rust FFI, such as cglue and abi_stable. However, there isn't much demand for this. Since most Rust libraries are very small, or contain generic functions and types, there isn't good reason to put in that kind of effort. You have to have a special case to make this worthwhile. Generic functions and types also cannot be compiled unless they have their types defined. When using a library with them, their code cannot be generated until the application using them defines the types being used with them.

Also shipping an entire gui framework in each single would mean enormous binaries.

You're overestimating the size of the binaries quite a bit here. The source code in iced is very simple so there's not much to compile and link. The vast majority of code is generated at compile time by the application. Code that wasn't used by the application will not be linked into it. Some of the smallest Flatpaks are Rust applications by the way. I'd imagine that the GUI code embedded into the binary would be within the order of a photo from a camera.

I'm guessing if every binary contains the gui code, I have to recompile everything on each bug fix in the gui library.

This isn't the job of an end user to worry about. Libraries receiving bug fixes is more a matter for the developer to be concerned about than the user. Regardless of what fixes that a development dependency receives, you still have to wait for the application author to release a new version of their application with an updated lockfile. A process where the developer has to validate that the updated dependencies have not caused any regressions in their application.

That would be hell for package maintainers.

Package maintainers already don't rebuild C applications when they receive commits with bug fixes. They will either wait for a release or withhold updates until the next point release. Only the more severe issues get special treatment that warrants adding patches to an otherwise frozen package.

It's generally not the job of the package maintainer to mess with dependencies without good reason and their own QA to validate that the changes they made haven't caused a regression. Those who do already have a CI in place to automatically rebuild packages when a source crate is updated.

[mmstick]

I've tinkered with the cosmic compositor a bit and so far, albeit basic, do like what's there. will it have the ability to choose which GPU it renders on? IE. having a display on GPU A, but being able to select GPU B for rendering?

this is necessary for a few features, but for an example of where this is useful, say you have dual gpus and do gpu passthrough. you can have a single monitor plugged into the host gpu. it would be really nice to be able to elegently remove the gpu from the server (much like eGPU) even if it is the only head, and be able to bring it back up when the gpu comes back (when a passed through gpu is brought back from a VM properly, it acts much in the way a an egpu coming back online).

I suspect as long as cosmic can elegantly handle loosing all of it's displays (I think this is an issue with some people's HDMI monitors too?), handle gpu hotplug (much like eGPU), and rendering on a separate GPU, the pieces should align pretty well for this usecase. since it is more or less a collection of issues people have anyways into one single usecase.

It will support multiple GPUs, and you may even get to see the compositor dynamically choose to render some things on a dGPU and other things on the iGPU.