[Mister_Snuggles]

It extends beyond desktop environments, that's only the most visible piece.

Closely related to desktop environments are the two major UI toolkits. Why does Kate have a different file picker than Gimp? Why does LibreOffice give me yet another file picker? On MacOS and Windows, the file picker is a solved problem.

Init systems, until fairly recently when most distributions consolidated around systemd, were in a similar state.

The current Wayland vs X situation is another example - some distributions prefer Wayland and its quirks, whereas others use X and its quirks. In this case, it seems pretty clear that Wayland is the winner and we're just waiting for everything else to catch up.

[badsectoracula]

> Why does Kate have a different file picker than Gimp? Why does LibreOffice give me yet another file picker? On MacOS and Windows, the file picker is a solved problem.

Because these file pickers are implemented by two different GUI toolkits that have a different idea of how file picking should be done. This isn't anything new, Xaw programs used their own (handmade) file dialogs, Motif had its own, Java/Awt had its own, Java/Swing had its own, etc. Unless you want to force everyone use a single toolkit (which is unrealistic for several reasons) you cannot get the same behavior everywhere.

Note that this isn't specific to Linux, in Windows and probably macOS you get the same unless you stick to applications using only the native APIs and avoid any cross platform application that use Gtk, Qt, Swing or any other toolkit that cannot tie itself to a single native widget library (and TBH even with some applications that do tie themselves to Win32, they sometimes end up implementing their own file pickers anyway).

And of course file pickers tend to be the most shared of GUI elements, when it comes to the actual UIs themselves even in Windows you get a ton of different toolkits, styles, behavior, etc that totally ignore the native look and feel (assuming there is one since Win32, WinForms, WPF and UWP all behave from slightly to totally different from each other, depending which ones you compare).

> In this case, it seems pretty clear that Wayland is the winner and we're just waiting for everything else to catch up.

Wayland is very restrictive for many uses and actually lacks several useful features compared to X11 - some it pushes towards the applications in the stack (so instead of a single solution that is shared among -say- 1000 clients you get 1000 solutions), while other stuff are simply impossible (unless you are XWayland which gets special status, leading to the ironic situation that even under Wayland the X APIs provide you with more functionality :-P).

[Mister_Snuggles]

You're absolutely right that the problem isn't unique to Linux, it was just the easiest example I had on hand and was relevant to the discussion. I could just as easily fire up a variety of programs on my Mac that feature different file pickers and GUI conventions.

Windows, as you point out, is kind of thrashing around when it comes to what it wants its GUI to be. I don't think the situation will ever improve there as Microsoft is very reluctant to break backwards compatibility.

> Wayland is very restrictive for many uses and actually lacks several useful features compared to X11 - some it pushes towards the applications in the stack (so instead of a single solution that is shared among -say- 1000 clients you get 1000 solutions), while other stuff are simply impossible (unless you are XWayland which gets special status, leading to the ironic situation that even under Wayland the X APIs provide you with more functionality :-P).

I will admit that I haven't dug into Wayland very much, but this is my impression as well. I try it (the Wayland KDE on OpenSUSE Tumbleweed) periodically, but it seems a lot crashier than X.

[badsectoracula]

> Windows, as you point out, is kind of thrashing around when it comes to what it wants its GUI to be. I don't think the situation will ever improve there as Microsoft is very reluctant to break backwards compatibility.

I don't think they need to break backwards compatibility, they just need to focus on one of their existing tech and try to make the other stuff behave similarly. There is no reason for example why they cannot provide new window classes (as in RegisterClass) that implement controls that look and behave similar to the UWP stuff - after all there are already a bunch of 3rd party "Metro/UWP style" components for other toolkits. It is just that none is "official".

They need to provide some unification (even if underneath things are less than ideal) and this needs to cover all the tech they've made so far - Win32, MFC (which can build on Win32), WinForms and WPF (and others, if i forget anything).

> I will admit that I haven't dug into Wayland very much, but this is my impression as well. I try it (the Wayland KDE on OpenSUSE Tumbleweed) periodically, but it seems a lot crashier than X.

The implementation aren't really a problem since they can be fixed, the issue is at the protocol level and even some of the goals/mindset that lead to it (e.g. the inability of clients to talk or share resources is considered a feature, but this is one of the thing that you need to implement reusable programs that work as components).