Most active commenters
  • charcircuit(4)

←back to thread

Xmonad seeking help for Wayland port (2023)

(xmonad.org)
88 points clircle | 12 comments | 18 Sep 25 00:04 UTC | HN request time: 0s | source | bottom
Show context
jmclnx ◴[19 Sep 25 23:38 UTC] No.45308107[source]▶
That is the thing with Wayland, it is much harder to create a window manager for Wayland. IIRC, fvwm decided not to create a Wayland version due to the difficulty.

When Wayland replacing X, lots of cool window managers and mini applications will be gone.

replies(10): >>45308167 #>>45308326 #>>45308396 #>>45308402 #>>45308487 #>>45308584 #>>45309873 #>>45310118 #>>45311190 #>>45311240 #
1. charcircuit ◴[20 Sep 25 00:16 UTC] No.45308396[source]▶
This isn't wayland's fault. It's the compositor implementing wayland's fault for not exposing a window manager API. Nothing about wayland prohibits the creation of a window manager API.
replies(4): >>45308435 #>>45308784 #>>45309845 #>>45311041 #
2. chongli ◴[20 Sep 25 00:21 UTC] No.45308435[source]▶
I’ve heard the same thing about Wayland and NVidia’s drivers. To me, it seems like Wayland was designed to push all the hard work onto everybody else. That way Wayland never gets blamed for anything!
replies(1): >>45308795 #
3. scythe ◴[20 Sep 25 01:08 UTC] No.45308784[source]▶
For practical purposes, the problem with Wayland from the WM-dev's PoV is that you're either implementing a huge project or you're depending on wlroots, and wlroots still isn't where it would need to be for implementing a simple window manager to be as easy as it was with X11.

From the Wayland devs' PoV, mainstreaming Wayland successfully shifted responsibility for doing most of the heavy lifting in the graphics layer from the neglected X-Windows project to the well-established KDE and GNOME. The state of wlroots and the ecosystem of personal WM projects is unavoidable collateral damage.

For an individual developer, perhaps the thing to do is take a page out of bbLean's [1] bag of tricks and implement your WM on top of one of the big two desktop environments.

https://bb4win.sourceforge.net/bblean/

replies(1): >>45308817 #
4. charcircuit ◴[20 Sep 25 01:09 UTC] No.45308795[source]▶
Not having a defacto compositor was a major blunder and resulted in an enormous delay to the project, reputational damage, and numerous challenges for app developers.
replies(2): >>45309303 #>>45309861 #
5. charcircuit ◴[20 Sep 25 01:11 UTC] No.45308817[source]▶
The problem is that compositors aren't giving you an API to target. Hyperland has plugins, but that is a whole other can of worms.
6. chongli ◴[20 Sep 25 01:51 UTC] No.45309303{3}[source]▶
What I don’t get is why they pushed the compositor onto WM developers in the first place. Compositing seems like way too low level of a task for a window manager to be concerned with.
7. Ferret7446 ◴[20 Sep 25 02:55 UTC] No.45309845[source]▶
Nothing stopped the adopters from waiting until that existed before pushing Wayland into their software and breaking many people's workflow either, yet here we are
8. hollerith ◴[20 Sep 25 02:58 UTC] No.45309861{3}[source]▶
Do you mean default compositor?
replies(2): >>45310204 #>>45311007 #
9. c-hendricks ◴[20 Sep 25 03:55 UTC] No.45310204{4}[source]▶
I think they meant like a reference implementation, wlroots came a decade into Wayland
10. charcircuit ◴[20 Sep 25 06:38 UTC] No.45311007{4}[source]▶
I mean they should have made Weston production grade and extensible so that others can integrate with it instead of remaking their own compositors.
replies(1): >>45311064 #
11. ◴[20 Sep 25 06:46 UTC] No.45311041[source]▶
12. ◴[20 Sep 25 06:49 UTC] No.45311064{5}[source]▶