The number of PRs for Cosmic you shared is very misleading. The parent repo is full of submodules, so if you want to present the number of PRs to Cosmic as a whole, you need to count the PRs for each repo. For example, the software library app alone has more than double (3/182) the number you presented (6/90).

ok that makes more sense, was looking for their main/largest repo with the most stars, but yeah given it's made up of multiple sub modules its PRs are highly under represented.

> Omarchy has some how managed to attract 134/782 open/closed PRs [1] vs 6/90 for CosmicDE (since 2022) [2]

You're linking to the PRs on one of many Cosmic repositories, the top-level wrapper repository. The total number of PRs on all Cosmic repositories it includes is far larger than Omarchy.

This is fine, but Hyprland/Omarchy is a different paradigm than you average Gnome/KDE distro... As much as I would love to love Omarchy, it is just not my cup of tea, I just like to operate on windows floating everywhere, and get pissed that I can't find what I'm after and Super+Tab two full rounds before landing where I want to be, I just like that, I thrive in this chaos... I settled for Bluefin which is by far the best developer experience I have ever had in my life, it is just the perfect distro for coming from either Windows or macOS...

The reality is that hyprland is not a desktop environment and, even with a few dozen extra packages installed, it doesn't cover even a quarter of the use cases something like KDE does.

For many people that's fine, but you're comparing apples and oranges.

The fact they are different is the point, and my preference is leaning towards the Hyprland/Omarchy approach of starting from an empty base that you script and stitch different features together (from a wider community of authors) to build my preferred DE instead of relying on a big release drops from a single vendor to provide most of a DE's features.

There's going to be room in Linux Desktops for multiple DE's, and everyone's going to have their own preference, mine's just leaning towards the Hyprland ecosystem.

I agree with this.

However, I have a Starlabs convertible tablet, which I have just not gotten comfortable with on Arch.

I've considered going the sxmo route, but the volume buttons aren't that good. So I'm thinking maybe KDE plasma? Maybe the hardware is just not good enough for me to be happy.

There really isn't a solid arch config, to my knowledge, on tablets. I'd love to have the scriptability of Omarchy on something that worked well with an OSK and touchscreen. It may be hard to do this, however, as elements like "Activate OSK when text box selected" might be reliant on DE properties. Im not sure

A UNIX graphical system without a proper developer stack, with frameworks for all layers, means everyone does their little thing, the people that can't be bothered just ship Electron or something just as bad, and for all user purposes to manage windows, and a couple of xterms, one could just be using FVWM from 1994.

Which is how I look to most of these new desktops.

> with frameworks for all layers

Not only that. Those frameworks are constantly changing. Old APIs are left behind while new, incompatible APIs are introduced swiftly. Fortunately, the Linux desktop is now perfectly usable despite all this, because most software runs in a terminal, the Electron engine, or in the web browser.

Which is basically why nowadays, my devices don't run GNU/Linux.

I am old enough that when I reached university, there were still green and ambar terminals to a DG/UX server used as timesharing system by all students.

Electron, the only application I tolerate on my private computers is VSCode, mostly because some plugins aren't available anywhere else.

Browser, I can have anywhere.

If it is to have the same experience as early 1990's UNIX, I can just as well ssh into a server box, VM or container.

Isn't this what Gnome/Libadwaita is trying to solve? They've been putting quite a bit of effort into it, and gnome builder, flatpak & related tech to have a proper developer stack for making GUI apps, and a community (gnome circle) to show them off.

At one time Gnome ejected a portion of its user base in order to become something that would work on tablets and phones as well as desktops - at least that seemed like the rationale. At that time it looked like there might be a market for linux devices with a UI and I don't know for sure but I think some money was spent to achieve this which is why objections by users were of so little importance.

Nowadays phones seem like a duopoly that cannot be challenged and tablets aren't very important anymore. Linux doesn't matter on the desktop because browsers are the UI and the apps run in the cloud. The whole GNOME/KDE/whatever effort is a bit moot.

Yes, both GNOME and KDE, but unfortunately never took off as many of us expected in the 2000's, and nowadays apparently tiling managers without such frameworks is what is cool.

Omarchy is mainly composed of configuration files which makes it a lot easier to interact with.

Exactly, much more hackable/approachable/sharable to be able to easily cobble features together.

"configuration as convention"?

> curated blank slate

On approachability, I think with COSMIC the use of Rust is going to negatively impact it in that area. I don’t think a scripting language needs to be used, but something more C-like in syntax is a must. Rust is intimidating looking to those who don’t know it which is likely to bottleneck contributions.

Or at the very least, an easier way to extend the desktop with extensions.

What made gnome extensions so successful (despite gnome breaking them every new release) is it's just JavaScript & CSS. You can learn & make a gnome shell extension in an afternoon. No need to learn C, GObject, etc.

For COSMIC, even the panel applets are full rust programs

Unfortunately Gnome extensions suffer from breaking frequently due to how they work.

The best design for extensions specifically is with a capable, well-defined, stable public API that can be hooked into by a scripting language. The extension APIs should be exposed with both official bindings for popular languages as well as plain C headers, so other language bindings can be easily written and extension authors can use Python or Lua or Ruby or whatever it is they like to write.

Rust is the “most loved” language for almost a decade now.

The syntax may be verbose in some cases, but that ignores the hype surrounding Rust. I don’t think they will be hurting for contributors.

One tends to love things that make life easy. If you spend all your time debugging memory errors or concurrency problems then rust might seem wonderful for saving you from those problems.

I'm still learning it but it doesn't really seem very joyous when trying to accomplish simple things. I'm feeling nostalgic for C actually. I don't end up doing a lot of concurrency and memory handling is a discipline that can be greatly aided by running valgrind on my unit tests.

I find Python joyous and I don't love Javascript but I'd much rather write UI code in that than any compiled language.

I think that writing UIs in a compiled language can be a pleasant experience, but it requires that the language in question be designed to put an explicit heavy emphasis on ergonomics and devs landing on the happy path by default. Rust doesn't really fit that profile and prioritizes safety above all.

Rust certainly has an enthusiastic following, and I’m sure there will be contributors from within that circle, but that hype has little impact beyond that crowd. The chances that your random user who gets an itch to contribute has adequate Rust skills is not high.