> Wayland is only supported by compositors that implement the wlr-layer-shell protocol. Typically wlroots-based compositors.
I'm really concerned about Wayland fragmentation. Will some tools work on only wlroot implementations and not others? X11 apps generally work across window managers, although the weird ones (tiling window managers like i3) may have some interesting things you have to work around.
If wlroots became the standard for all window managers on Wayland and everyone used it, I guess it would be fine. But if not, we're going to see a lot of apps that have to be adapted for each and every composer.
I don't know why people are so afraid of fragmentation in this respect. There are lots of "de specific" protocols that are well supported everywhere like org.freedesktop.Notifications.
If the world can agree on Wayland then desktops can agree on some dbus interfaces for doing stuff like screenshots, screencasts, and automation.
Wayland is a shiny new thing and lots of people are writing compositors since it's suddenly possible for people to write them in a way that you simply couldn't with X11. The ecosystem will eventually mature but I think it would be a mistake to recreate the Xorg monoculture with wlroots. People seem to see the value of multiple browser implementations agreeing on standard but not display servers.
I'm personally concerned because I like to use "niche" tiling WMs (I used Ratpoison then StumpWM for over a decade, then I switched to a rather heavily customized DWM a couple of years ago).
Even with a relatively monolithic and "opinionated" protocol such as X11 it's not uncommon to encounter applications that don't play very nicely with alternative paradigms (because they expect a tray to be available, or to be able to place floating windows anywhere they want for instance). Still, overall with a few hacks here and there it works mostly very well. Basically I know that we're 2nd class citizens within the unix desktop world but at least the X11 model gives us enough of preemption to get things working mostly correctly.
From what I see of Wayland I'm very concerned in the long run. Not being able to just beat a window into submission X-style seems like it would create a world of troubles.
And because tiling environment are fairly niche I don't expect the ecosystem to organically evolve solutions to all of these problems.
And if you think "well just stop using tiling WMs and use whatever else is using you weirdo" please do note that these issues are also often the same that are encountered by people with disabilities who need to rig their UIs in certain ways to make them usable. Also you'll have to pry my tiling WM from my cold dead hands, you heathen.
> Even with a relatively monolithic and "opinionated" protocol such as X11 it's not uncommon to encounter applications that don't play very nicely with alternative paradigms (because they expect a tray to be available, or to be able to place floating windows anywhere they want for instance
I think in the long run you’ll actually be quite happy with Wayland for your use-case since Wayland removes a lot of the weird things that Windows can do without the help of the (tiling) compositor. A tiling compositor actually has far far more power to beat windows into submission than an Xorg based WM ever could. Surfaces can’t move, steal focus, put popups anywhere without the compositor having a say and, potentially, just saying no.
And GNOME has removed support for xembed tray icons in favor AppIndicator which is just a generic dbus interface which a tiling WM can actually sanely implement.
I tried a bunch of tiling window managers over the last two years, and found that the choice of X11 or Wayland does not make much of a difference with regard to the “second class citizen” effect you described. What finally solved it for me was switching to GNOME (ie. mutter on Wayland) with the PaperWM extension. Fundamentally, I’m running a conventional desktop with no tearing and standard, widely used solutions for keyboard shortcuts, the clipboard, screenshots, and floating windows, so graphical applications look and feel correct even if they are a bad fit for the tiling model. Tiling is then implemented by PaperWM at a higher level, in JavaScript, leaving the complexities of hardware accelerated, animated compositing to GNOME. It’s a good combination – I’d like to see more tiling window managers designed to take advantage of hardware-accelerated compositing.
There are tiling window managers for Wayland. Sway is one that is meant to maintain configuration file comparability with i3. But yes, obscure tiling managers will need to be rewritten for Wayland.
I'm looking at sway and it looks promising (although I wonder how it deals with the many weird corner cases that X11 tiling WMs have had decades to fix and work around) but Sway's home page linked to the wlroots project which is:
>[...] a modular basis for Sway and other Wayland compositors to build upon
I was curious to see what that looked like so I went on the github and the first sentence on the README is:
>Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 50,000 lines of code you were going to write anyway.
My jaw literally dropped when I read this. It seemed so wild that I actually cloned the repository and ran sloccount myself to check if there was a catch (there isn't, master is at 53k lines). My DWM is 3k lines and it's fully featured as far as I'm concerned.
I realize that it just pushes a lot of that functionality (and code) into X but at least it separates the concerns, my WM doesn't ship with half of the X11 source code as a hard dependency. Also X11 has been battle tested for literally decades by now, it's not a fast moving project (well, arguably it's quite the opposite, hence the very existence of this discussion).
I haven't looked very deeply at Wayland so I won't say that they're doing it wrong, maybe I'm just missing an important aspect, but the more I learn about it the more it feels like they've thrown the baby out with the bath water.
X11 can be hugely hacky at times and some of it is seriously outdated at the conceptual level, but it also does many things amazingly well, arguably better than any other mainstream desktop environment out there. It's an incredibly flexible, if a bit idiosyncratic system. Wayland seems to fix some of its flaws by introducing a brand new system that comes with its own set of drawbacks.
The more I learn about this, the more I start to think that there needs to be some kind of middleware library implementing all these missing features from Wayland that all Wayland compositors are going to to need anyway.
Then the compositors could just use this library instead of every one of them duplicating effort and coming up with their own mutually incompatible ways of doing things.
In fact, this library could even be protocol-agnostic, and be able to talk to both Wayland and X.
>The more I learn about this, the more I start to think that there needs to be some kind of middleware library implementing all these missing features from Wayland that all Wayland compositors are going to to need anyway.
>Then the compositors could just use this library instead of every one of them duplicating effort and coming up with their own mutually incompatible ways of doing things.
That's what wlroots is, except for...
>In fact, this library could even be protocol-agnostic, and be able to talk to both Wayland and X.
... because that's outside its scope. The point of the middleware is to interface with the wayland protocol. It's not "protocol-agnostic".
> There are lots of "de specific" protocols that are well supported everywhere like org.freedesktop.Notifications.
except when they aren't - I had a firefox bug for a couple years where the browser showing a notification would completely hang it for at least 15-20 seconds
I had this as well with Mumble. The problem was that I didn't have a notification daemon running, so the application was timing out trying to connect to the respective bus. Autostarting a barebones notification daemon like Mako fixed the issue for me.
It breaks multiple things for me and does nothing of note I care about. The things I want to work will either never be fixed or will be fixed in the distant future.
Since I have no desire to lose functionality or work around issues I will revisit the situation either when every major issue is resolved or within 1 year of major apps like Firefox not working on X even with a a user contributed build.
I'm really concerned about Wayland fragmentation. Will some tools work on only wlroot implementations and not others? X11 apps generally work across window managers, although the weird ones (tiling window managers like i3) may have some interesting things you have to work around.
If wlroots became the standard for all window managers on Wayland and everyone used it, I guess it would be fine. But if not, we're going to see a lot of apps that have to be adapted for each and every composer.