XMonad for Wayland — call for help

Announcements
#1

We on the XMonad devteam (Tomáš, Tony, Yecine, and myself) have been collecting contributions for the past two years with an eye toward paying someone to work on a port of XMonad to Wayland, since none of us is up to the task. We think we now have enough contributions coming in monthly to pay for someone to work with us on it.

Problem is, we have no idea who can do this. So this is a call for help, looking for someone who can write it. There is an existing project but it’s badly bitrotted, including using a very old and buggy version of wlroots, and L-as has had little time to revisit it. It’s not clear that it’s worth revisiting.

One problem that’s unlikely to be solvable is that Wayland programs don’t set distinct identifiers that a manageHook could use, so the appName and className hooks can’t be ported. We welcome information to the contrary, though.

So, help? Comments and especially proposals welcome.

50 Likes
#2

Isn’t this what app_id is supposed to be for?

GTK4 apps, for example, should set this automatically. (Less reliable with GTK3, in my experience; no idea what other toolkits do.)

#3

It has to be exposed as a window property. Property dumps I’ve seen from Wayland don’t seem to include it. If there’s a way for the window manager component to query it then it might be supportable, but that’s one of the reasons we need someone familiar with Wayland.

#4

Wayland-ified XMonad would have to be a compositor, not an independent program like an X window manager. Compositors will have access to the window’s app_id because they play the ‘server’ role in Wayland.

In a Wayland GNOME Shell, for example, you can pull up the Looking Glass console (Alt+F2, lg) and type global.get_window_actors().map(a => a.meta_window.wm_class) to get a list of app IDs (the wm_class name is legacy, because this merges the app_id property of Wayland windows with the WM_CLASS of X windows).

If Wayland-ified XMonad is going to be based on wlroots (and I’d be shocked if not), the wlr_xdg_toplevel struct is where you’ll find the app_id field and the set_app_id signal (for when the application changes its app_id).

I’m probably not the expert you’re looking for, to be clear—and I’m not at all familiar with XMonad—but I’m a big fan of Wayland and there’s no reason at all to fear this particular feature being lost.

8 Likes
#5

I’m a big fan of XMonad (I’ve been using for years). What would be the advantage of using Wayland ?

3 Likes
#6

Mostly that X11’s days are numbered (although I expect it to last at least until 2030 due to Red Hat’s contractual obligations). But video drivers are already starting to become less reliable as chipset manufacturers refocus on Wayland instead of X11. This is already affecting games and other programs which are becoming more stable under Wayland than X11.

8 Likes
#7

I have a HiDPI laptop screen, and text rendering never looked quite right on X. With Wayland, this is painless. I’m now using Sway (an i3 clone); it’s fine, but I still prefer XMonad.

9 Likes
#8

I might be interested in working on this! I’m a longtime user of xmonad and I’d like to see it make the transition to wayland. I’ve done a bit of haskell but more comfortable in elm these days; lots of C++ experience but not specifically x11/wayland stuff. Could hopefully read the source for sway/etc and apply to haskell.

12 Likes
#9

I assume the person could make their own hours? What would be the minimum hours per week you’d be looking for?

#10

I don’t think we have any expectations yet. We also still don’t quite know what we’re going to do; there’s been a competing proposal which I’m considering combining with this. That said, I’e also been ill for over a week and less than available for even the usual support things, so I haven’t put a lot of thought into it of late.

3 Likes
#11

Hi @geekosaur,

I’m a Haskell (2 yr) and C++ developer and a dedicated XMonad user for three years. I currently lack experience with Wayland and XMonad core, but I’m really so interested in this project and ready to learn and contribute full-time to the project.

12 Likes
#12

Wow, this is fascinating. I have mostly experienced with C++ and Rust, but I learned Haskell for my last job (not really a good Haskell developer, but at least I can code a bit). What I lack experience is with Wayland. If there are any small tasks on the GitHub or somewhere else I can take a look would be awesome.

3 Likes
#13

Would it be redubbed “WMonad”?

5 Likes
#14

Although I am not by any means an expert on X11 protocol, I’ll give some sort of comparison to clarify some conceptual differences between X and Wayland.

Probably it’s pretty clear that Wayland compositors are themselves a display manager, but this doesn’t mean that it should be harder to develop a window manager (at least nowadays). Nonetheless, thinking about server-client architecture isn’t accurate when talking about Wayland compositors.

Another overlooked part are Wayland protocols, which are defined in XML files. While is not the same concept, think about message passing. libwayland just encodes and decodes those messages, not caring about the actual implementation that is done by the compositor or the application toolkit.

Until not that long ago, there wasn’t any kind of standarization in the Wayland world, while X11 had for a long time clunky basic extensions like RandR and Xinerama. Although it’s not 1:1 feature-wise with X, Wayland has almost reach that point. With those protocols, features can be developed and implemented, and this is not a limitation of Wayland, that received wrong criticism about its usability and security design.

Before writing the XMonad compositor itself, first wlroots bindings should be done (check also hsroots project). Ideally, those bindings should be XMonad agnostic. If I remember correctly, the identifier for X applications runing inside Wayland are called class, so className should be refering only for X applications (it’s just an example, but maybe some breakage on config files should be expected at some point).

Despite all difficulties, it would be much easier to integrate with another DE (ex. KDE or XFCE panels) as long as they support the same protocol than wlroots (in this case, wlr-layer-shell protocol). That also applies for XMonad related projects like xmobar.

Hope that we keep discusing about more fine details, specifically about how to design and implement those in XMonad.

8 Likes
#15

We’re not worried about config file compatibility beyond the basics (same hooks and such, to the extent possible); this is expected to be a different window manager fitted to Wayland, not simply a port of an X11 window manager. Similarly, we’re expecting it will develop its own contrib archive, as it’s expected that porting the existing one will be difficult at best because so many things require calling out to Xlib in the current one.

5 Likes
#16

That sounds great! Likely, XMonad should shift its design to a compositor + (graphical) shell. This change would bring some key advantages like troublesome-free restart/reloading (something that is not possible in Wayland if compositor is also restarted), recompiling will be faster and distro packaging would be a little bit easier.

#17

Seems like a good project for Haskell Summer of Code …

2 Likes
#18

I think it might be too big for SoC, plus we’d have to provide mentoring and I am not at all sure any of us can really help there.

1 Like
#19

Something I have always been wondering, is the type class based designed of XMonad a necessity or is it a anti-pattern ?
I works sure, but it gives horrendous error messages (Types are so big, that it is nearly impossible to actually keep up with type annotation).

I’m not sure if it is possible to do it differently and it might be not XMonad at all , but if you are not writing “simply a port” it might be something worth considering.

3 Likes
#20

The fact that the new way of Xmonad could be a brand new Wayand version could be great. But only if all the current features of xmonad , xmonad-contrib and xmonad-extras will be available.
We love xmonad beacause all its features and modules, I think nobody wants a bad imitation of what xmonad currently is.

This will of course require time. So you need a preliminary draft of a future roadmap.
This is what I suggest:

  • xmonad from 0.17 series to 0.19 series : total feature freeze ( no new features to be added) , bugfix , code cleaning , Xwayland full support and compatibility.
    Xwayland compatibility is important in my opinion , because it will be needed until the new xmonad for Wayland will be ready and full featured, this will permit people to use both the new Wayland version and the Xorg version , even in the case that Xorg will be definitively shutted down

  • xmonad 0.20 going on : may be renamed to wmonad or a more not graphical server related name . Here I cannot suggest the right approach , but of course the final work should be a full featured xmonad clone.
    It will need of course a tons of feedbacks and testing, so in my opinion is important that this new implementation can be installed along side the classic xmonad until it will be ready, also considering that this xmonad Wayland version will be absolutely a long, long journey.

2 Likes