[simias]

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.

[Spivak]

> 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.

[sjy]

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.

[nsajko]

What you fear is sadly true. See my top-level comment in this thread for some elaboration.

[djsumdog]

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.

[simias]

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.

[pmoriarty]

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.

[Arnavion]

>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".

[HeadsUpHigh]

Wlroots is the middleware library. Other wayland tilling wm use it as well.

[sergeykish]

> dwl - dwm for Wayland

> dwl.c, 2000 LOC

https://github.com/djpohly/dwl

wlroots should be compared with X.Org Server, 370000 LOC

https://github.com/freedesktop/xorg-xserver

[majewsky]

> My DWM is 3k lines and it's fully featured as far as I'm concerned.

For fairness, you should count the hundreds of thousands of LOC in Xorg as well. From that PoV, 50k might actually be pretty lean.

[mcguire]

Rewritten and add compositor functionality.