Like if you want to select a desktop and are kind of new to desktop environments, maybe aim for the (imaginary example here) DE-5 level of standards-adherence. DE-4 and lower might suck in various ways even though they could have cool new features.
There are way too many benefits from the huge variety of DE approaches, including the benefit that Linux-critics often hide behind critique of a single desktop experience, which is lazy and attempts to steal focus from exactly this open, creative, diverse approach that is the jewel in the Linux ecosystem's metaphorical crown.
It's definitely great to see the groups working together on these projects that benefit everybody.
I'm using a very minimal system without a lot of the easy to implement features on purpose, but absolutely can not live without some of the more difficult ones. So for me the adherence would be cherry-picked parts from 3, 4 and 5 and impossible to place on a chart. I don't think it would be a good fit for the modular unix philosophy.
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
[2] https://specifications.freedesktop.org/basedir-spec/basedir-...
As opposed to, say, standards that are based on general user experience aspects. Does the control panel offer printer settings yet, for example.
At the lowest level you have the kernels (KDE and Gnome both run on Linux AND BSD) which may or may not have drivers built in. Then comes the distributions which are opinionated in the kernel versions, packages and patches they add.
Some of those packages are desktop environments or window managers and they are opinionated in how they run other packages and their lifecycle. Some full featured others are tiling. Some of them run on both Xorg and Wayland.
Last we have the actual packages, and they need to work in all these different environments, sizes and lately different protocols. They need to support different drivers, permissions and file system hierarchies. They do this by relying on each other, a package handling video focuses on supporting video and sound drivers so other packages can import that package.
KDE might have a very polished and up to date settings panel, checking for all drivers and their features. But in reality it works as intended on Ubuntu, but Debian is behind and doesn't want to patch the drivers because stability, on Arch there was a regression and most of the BSDs don't even support the driver. And one time Linus came along and didn't listen to the warnings and fucked it all with one line.
Nobody controls all of these pieces and they're so spread apart that what might seem as simple as a panel for printer settings quickly gets very complicated. But I wouldn't have it any other way. For those who want the one size fits all there are already options.
I used to be on this hill. All this leads to is inoperable software where each integration point is liable to break. I want to get away from the spyware that is Windows, the walled garden that is MacOS. If a uni-desktop is the price we pay, so be it.
And it's gotten better too - did you know KDE3 had it's own sound mixer daemon? It was called ArtsD. Now we have pulseaudio, or whatever, which is great and cross desktop
DBUS made it everywhere as well - I believe initially KDE3 as well did not have DBUS but had something called, DCOP. so - yeah things have improved a lot and many things - even command line tools 'playerctl' interop well based on this.
More fun is also like libreoffice is compiled with many different file pickers, so on KDE you can use the native Qt extended KDE file picker, and on Gnome you get the GTK one.
What's the difference? If everything works perfectly with everything else, and the standards adherence is so high that you can't tell the difference which apps are from which organization, then how is that not a "unified DE"?
We of course already have something like this (POSIX, Freedesktop, etc). However neither is abided by very well and neither of them go far enough up the stack to deal with certain very visible issues of desktop application incompatibility.
What I think could be done to fix some of the compatibility issues (like when running QT on gnome or GTK on KDE or applications that eschew them both and have janky window decorations) would be some more serious standardization onto something like Wayland. We would of course need something more than a reference implementation for that, but fundamentally I don't see why that would be too restrictive for projects that still want to make their own widgets.
There'd also be a standard for e.g. IPC-based interoperation with file picker dialogs, such that if you were running GNOME as your DE, QT apps would (tell the DE to) pop the (GTK!) file picker to open a file, which would then signal back to the app through some standard message format for describing picked files (maybe with the file-handles themselves passed over a Unix domain socket, if you want something like macOS's sandbox-piercing file-open-intent tokens.)
There'd be a single "accessibility DOM" standard, so that a GTK screen-reader could read the text out of QT apps.
There'd be a single shell namespace standard, with one common set of abstract data types (with multiple implementations), so that opening some GVFS virtual folder in a KDE app would actually work — probably through D-Bus integration between the KDE app and some libgvfs host runner agent.
And so forth.
The ecosystems of each DE would remain distinct in development, with apps designed to fit well together... but the feeling of DEs being walled gardens would be gone, because the various standards would force each app to be a "chameleon" to whatever DE it's running under.
There are a few tiny attempts at this under FreeDesktop. xdg-open(1) is a good start. But we could be doing so much more.
OTOH, if you think there are good, detailed reasons why XFCE is not KDE is not Gnome is not LXDE, then you can probably see why standards are helpful, insofar as they can be designed to be reachable without compromising unique leverage points.
No thanks. GNOME dev hubris is the reason I use KDE
Personal example from trying GNOME out recently: I have an external webcam, which means I need to move the GNOME panel clock since it's in the top middle of the screen (and thus blocked by the base of the webcam). You would _think_ that would be easy, but you have to get an extension just to move the clock! Apparently each panel "widget" (this may or may not be the official term) defines its own position on the panel. So, to move something, you need to either find an extension that does it (Frippery Move Clock[0] in this case) or edit the widget code yourself.
Maybe someone can chime in with a technical explanation, but my cynical take is that the GNOME devs don't even trust users to be smart enough to customize their own panel without breaking things.
</vent>
They say this is desirable functionality, but that they would want to subsume termites features in VTE and Gnome Terminal, and that was their rationale for rejecting the patch. Then they didn't deliver those features in a timely fashion.
That's just abhorrent behavior.
I'm gonna say citation needed on that one. In fact, I have seen many rants about desktop software trying to look like touchscreen software.
Now I'm writing this reply from KDE, quite comfortably, and it's quite stable. Comfortable, even. And it doesn't get stupid and die when I plug/unplug monitors and stuff.
This would be terrible. Gnome and KDE have pretty conflicting ideologies. Gnome is super opinionated and Mac-like minimalist. KDE is all about user choice.
If they'd collaborate it would end up something in the middle which would suit nobody.
...you can't compare minimalism/configurability in this way
Ed: one minor (but somewhat understandable annoyance) is the lack of a free/reserved for users modifier key. Macos with the adoption of bsd uses both command, option and control (even though it uses command for core things like copy/paste). The windows/super key is a blessing on Linux pcs - as it generally can be used for just that - window management).
I know some rebind caps lock as a super (ed2: I mean "hyper", I think) (aka ALL THE MODIFIERS) key on Mac - but that leaves control in the wrong place :/
Maybe there's no RSI in Palo Alto?
The problem with this is that Mac, unlike Gnome, actually works. Gnome just has weird holes where old functionality was removed (like application menus!) and never replaced.
Yeah. Without proper window management, middle click and other things I need 3rd party apps for.
Of these, I would say that Cinnamon is one that could be comparable to XFCE or even GNOME and KDE. Seriously, it's good. The system settings menu has all of the options one could need and the look and feel of the dektop is very customizable.
I'm a KDE user, but if it ever stopped working/disappeared I would use Cinnamon. In fact I plan to use it whenever KDE Plasma 6 releases to wait out until the it becomes more stable.
IIRC KDE committed to never break users again like they did with the first releases of KDE 4. It's expect the first releases of Plasma 6 that the distros will actually ship to be stable, and to be mostly a Qt5 → Qt 6 upgrade. You should be able to run a stable version of Plasma (5 or 6) in any case during this period. KDE 3 to 4 was a disaster; last versions of KDE 4 were rock solid. First versions of Plasma 5 were a bit lacking but rapidly became very stable and usable, and you could actually keep using KDE 4 in the meantime. I expect the Plasma 6 transition to be even smoother. I hope I'm not wrong.
But otherwise I agree, Cinnamon seems very good and I tend to recommend it and pick it for people who I install Linux for.
What were your issues? What was the distro?
Forgive the vagueness, but I don't believe in memories and haven't kept a journal. Still, as completely unreliable and untrustworthy human memory is I am inclined to believe I had issues with Plasma 5 during the transition period.
Either way I think that still sounds better than the old 3->4 migration, and hopefully 5->6 can be better still!
...though I do lament the loss of Desktop Cube.
Of course, coming from Awesome I am often annoyed at how Plasma doesn't have per-screen (X11 monitor, if I'm not mistaken) tags and per-X11-display workspaces don't really work that well.
I'm not really against it, but I don't use KDE or Gnome (or any of the others in your list) and it concerns me that people might start thinking of those as "being Linux". I'd hate to see a future where "We support Linux" means KDE or Gnome.
On the other hand, I have to admit I'm not really sure what that would mean. I guess only having "Flatpak" as an option would be a bummer, but I don't see that happening with the distros I use.