Wayland Support

[xavier83]

Since wayland is becoming the mainstream display server for linux and X will only be supported through xwayland, would it make sense to support wayland too?

[Delapouite]

Should this alternative project be renamed wmonad?

[geekosaur]

Not happening, because xmonad is too tightly tied to X11. No matter how hard you try, the result would not be compatible with xmonad, its contribs, or any configs.

Significant parts of xmonad are also not applicable to Weston because they are no longer part of the window manager component; they were moved to the compositor or application level themes, etc.

[vivid-synth]

Looks like re-implementing for Wayland wouldn't be a giant project, though:

$ find . -type f | grep -v -e '\.git' -e '/tests/' | xargs wc -l | tail -1
  4495 total

[colonelpanic8]

Not happening, because xmonad is too tightly tied to X11. No matter how hard you try, the result would not be compatible with xmonad, its contribs, or any configs.

I can't say that I'm an expert on this topic, but I'd be surprised if there weren't any parts of the code can be reused. I would guess that StackSet might be eligible for reuse.

[geekosaur]

On Sun, Dec 4, 2016 at 1:04 AM, Ivan Malison ***@***.***> wrote: I can't say that I'm an expert on this topic, but I'd be surprised if there weren't any parts of the code can be reused. I would guess that StackSet might be eligible for reuse.

StackSet's about the last thing you want to reuse, considering that it's why e.g. floating windows behave insanely. In Wayland, the layout becomes a plug-in for the compositor and much of the rest goes into the client/application side theming. There is no "window manager" as such. I'm not sure you can even *do* something like the manageHook without introducing weird and potentially deadlock-y interrelationships between them. (The "ports" of xmonad to native OS X don't even try; there's nowhere to hook them in. It's much like Wayland.)

…

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

[heyakyra]

would it be worth a possible long-term rewrite for wayland support? it might be nice to adopt a client-server model like herbstluftwm in that case as well!

tangentially: https://github.com/abooij/sudbury

[moljac024]

Significant parts of xmonad are also not applicable to Weston because they are no longer part of the window manager component; they were moved to the compositor or application level themes, etc.

Total noob question but isn't Weston the reference compositor? AFAIK you don't write stuff on top of Weston, you write something LIKE weston. As I understand it, your compositor IS the window manager. Looks like some tiliing wms/compositors already exist, namely way cooler and sway.

[geekosaur]

Maybe that's the current story. I can say for certain you do not write for *Wayland*; Wayland is a protocol and a generic graphics API. You could write a 'Wayland' implementation that sits on top of xcb; it would not be compatible with what Red Hat has been working on, it would be a Wayland-protocol interface to X11 APIs. Then again, if they are handling this the same way they are handling Gtk (explicitly not supporting non-Gnome, or even third party Gnome apps), they probably don't see a reason to name something that they think shouldn't exist, namely a general interface compatible with their 'reference' implementation.

[mgsloan]

StackSet's about the last thing you want to reuse, considering that it's
why e.g. floating windows behave insanely.

What is insane about floating windows? Just that they occupy a position in the StackSet but are not tiled? It works just fine for me..

Not happening, because xmonad is too tightly tied to X11. No matter how hard you try, the result would not be compatible with xmonad, its contribs, or any configs.

Not sure how much I buy this. True, you cannot guarantee full API compatibility, and currently the XMonad module re-exports Graphics.X11 and Graphics.X11.Xlib.Extras. However, XMonad configs tend to be quite high level and do not do anything very X11 specific. I think it is quite possible to support nearly everyone's XMonad config.

There are some things like KeyMask, etc that show up, but compatibility shims for that could be implemented.

So, basically, I think this is far too pessimistic. It is fine if you don't want to implement it, I probably don't want to either. However, if some sufficiently motivated individual came along, I don't think we should discourage them from adding a wayland flag to xmonad / xmonad-contrib. There would be huge API differences with this flag enabled, true, but I bet it could be done such that most configs require no changes.

I see that the "Way Cooler" project has a D-Bus extension protocol. I haven't looked into details, but perhaps a compositor implementation like this one might be able to delegate the window management to something external.

I am particularly interested in Wayland support for the following two reasons:

• It is now the default in Ubuntu, so it will probably be better maintained. It will probably take a while for the xorg side of things to drop in quality, but it might just happen.
• Wayland can make it way harder to do keylogging. AFAICT, modulo security bugs, keylogging will now require either the blessing of the wayland implementation, or it will require super user permissions.

"Way Cooler" does indeed seem cool. I've liked messing with Rust, it's my 2nd favorite language I think. Setting up a new laptop soon, gonna try out a few different linux distros - probably Manjaro or Antergos (basically, Arch made friendly), possibly NixOS, and newest ubuntu. If newest ubuntu wins then I'll probably give "Way Cooler" a shot.

[geekosaur]

We don't wrap X11 much at all, and the few things we do expose Xlib (not xcb! which would make things easier) types.

Floating windows have lots of problems; try focusing one and watch the window stack rotate to something quasi-random (it will depend on what was focused on that screen when the float appeared). There are very few places where you could correct this by adjusting the StackSet; most of the hooks where you would want to do so run under control of XMonad.Operations.windows which is using its own (modified) copy of the StackSet which will replace the exposed one after the hook runs. (About the only hook that could actually modify the StackSet is handleEventHook).

sjanssen looked at both switching xmonad to use xcb and trying to change the StackSet to behave more sanely, and decided neither could be done without breaking existing configs. (I have to agree, at least in the case of StackSet; it was a horrid UI decision and I would like it to go away, but replacing it breaks too many things.)

In any case, the bigger problem is that there isn't a "window manager" by the X11 meaning of the term in Wayland; you'd have to split most configs into three pieces, and good luck getting them to work well together in their new homes if they need to interact in any way more involved than defaults (compositor for window placement, theme for window decoration, and a third user-written app for user interaction).

@Ongy has been working on a replacement for xmonad under Wayland, based on Sway. https://github.com/ongy/waymonad

[mgsloan]

I see! Thanks for the info @geekosaur .

sjanssen looked at both switching xmonad to use xcb and trying to change the StackSet to behave more sanely, and decided neither could be done without breaking existing configs. (I have to agree, at least in the case of StackSet; it was a horrid UI decision and I would like it to go away, but replacing it breaks too many things.)

Interesting! StackSet does strike be as being a bit too "clever". TBH I never found zippers to be all that nice to work with. Very clever, certainly.

I suppose I have had some issues with floating windows and when they are considered to be part of a particular workspace. Haven't seen any rotation of the StackSet on focusing though.

II wonder if sjanssen still has a wip version of that code laying around? Perhaps can do an XMonad 2.0 release that is free to break compatibility? I realize that XMonad's small core is one of the cool things about it, but I think some xmonad-contrib stuff could be made a bit more canonical and involved in the default config. Stuff like EZConfig and perhaps a few others.

Would require someone that was sufficiently motivated to do a bunch of good changes for an XMonad 2.0. Not me at this point.

In any case, the bigger problem is that there isn't a "window manager" by the X11 meaning of the term in Wayland; you'd have to split most configs into three pieces, and good luck getting them to work well together in their new homes if they need to interact in any way more involved than defaults (compositor for window placement, theme for window decoration, and a third user-written app for user interaction).

Indeed, it seems unfortunate that they did not make a protocol for window management. As is, the window managers will either also be compositors, or they will rely on a particular compositor.

[Ongy]

Indeed, it seems unfortunate that they did not make a protocol for window management. As is, the window managers will either also be compositors, or they will rely on a particular compositor

To my understanding, merging compositor, window manager and display manager (mostly input -> window translation) was one of the reasons they wanted to drop the X architecture.
Wayland is supposed to be more general than just a "desktop" window protocol.
Which becomes somewhat obvious when you realise the ivi shell existed for ever, and they are on the unstable v6 version of xdg_shell (the protocol on top of wayland that makes somewhat normal desktops possible).

As to, doing this over generic IPC with some existing compositor:
Since the architecture is shaping to be multiple compositors based on shared libraries (evdev, libdrm, kms) I doubt anyone will be happy to export the amount of control we want to have over such an IPC.
Simply because at that point it would be easier to just use the same libraries and write your own version.

This is what I'm currently investing way too much time and thought into.
BUT: this is a project on its own. I will break things. At least your config, probably some workflows.
I also won't make any promises/guarantees/estimates to when or even IF this will ever be at a state anyone who's less crazy than me can use.
If you have worries about how things will work out, feel free to create issues or join me in #waymonad on freenode (which I have been cheeky enough to create already) and talk with me.

Small correction: It's based on wlroots not sway itself.
wlroots is a subproject of sway created to replace wlc for them.