1. 25
  1.  

  2. 10

    I really bugs me how basically every Wayland article has to constantly take swipes at X.

    Anyway, I have my customized X window manager and a custom taskbar too that I like quite a bit and weren’t too much work… I’m planning on basically never leaving, but if I did, I’d probably write my own compositor to bring my workflow with me. This makes it sound like that would be a significant pain. Whelp, I wonder how long I can hold out.

    1. 6

      A Wayland compositor written in Zig: ifreund/river

      Isaac talked about his experience choosing C vs Rust vs Zig in this talk and he also has an upcoming talk at FOSDEM 21.

      1. [Comment removed by author]

        1. 6

          Uh… that’s, like, an essential part of any compositor. You can’t use it as a daily driver if it only runs nested in a window.

      2. 5

        Wayland is the “new” (13 years old already) display server technology on Linux

        Wayland works on the BSDs as well. I’ve tested it successfully on HardenedBSD. :)

        1. 4

          If you posted about this I’d upvote it. I didn’t know anything at all about the state of Wayland on BSD and had incorrectly assumed that it wasn’t a thing at all.

        2. 4

          it sounds like there is some fundamentally flawed architectural feature in wayland if writing a tiling window manager is hard. in much the same way as X had problems because it adopted a model that offered flexibility over where the client and server were sitting in the network, but traded off things for the overwhelmingly common case that everything was sitting on a single node, single user machine, is there some overly flexible architecture in wayland that trades off things you want to do when you know that at the end of the day there’s a rectangular block of pixels that you have absolute control over?

          1. 7

            is there some overly flexible architecture in wayland that trades off things you want to do when you know that at the end of the day there’s a rectangular block of pixels that you have absolute control over?

            No trade-offs that I know of, you can take a look at the protocol if you have the time, it’s a simple IPC with some specialised data structures.

            Regarding the ease of writing a tiling WM, the approach should be the same as on X11: you write a program that calls the API of the display server, just replace X11 with Wayfire, Mutter, KWin etc. The problem today is that there is no extensible wayland compositor with a full-fleshed fully-fledged API as far as I know. Wayfire was certainly built to be extensible, you can try it. KWin can only be scripted with JS afaik, and Mutter (GNOME’s compositor) is also available as a library, but there are only two window managers that I know of based on libmutter: Mutter itself and the Pantheon (DE of elementary os) window manager which doesn’t even support wayland yet.

            So, it’s not a problem with Wayland itself, it’s an ecosystem / adoption problem. The most common use for Wayland (GNOME, KDE and Sway) is very good today, but when it comes to “enthusiast” software, not so well.

            1. 3

              Wayfire is certainly “with a full-fleshed API”. Most of its default functionality is in plugins. If you don’t like the stock tile plugin you can write a different one that does whatever kind of tiling you want :)

              1. 3

                I should’ve been clearer (apart from writing full-fleshed instead of fully-fledged by mistake), it is not “recognisable” , it doesn’t have some API docs that I know of. Granted, with a slow and steady adoption by enthusiasts, it may reach this point.

                My gut feeling though tells me that it’s easier to write a Wayfire plugin of any complexity than a window manager with XCB, from my experience the XCB APIs for window management is rather obtuse and not documented very well.

          2. 2

            Well, I don’t know if I should, but I sure hope that someone writes a Wayland compositor in Common Lisp. Not Lisp bindings, but Lisp all the way down, or roughly as far the way down as I get today with StumpWM & X11. I like being able to dynamically extend by window manager in Lisp, and I would prefer to avoid C & C++. It is amazingly productive to be able to delve deeply into the call stack of a running Lisp system; being stuck using a bunch of bindings for a static library would be a real regression.

            1. 2

              So I would like to do so someday (I’ve given it a couple of Sundays last year.), Lisp all the way down et al. Except and approach like the one CLX took is not possible in Wayland. For one, because a compositor takes some responsibilities that the XServer had you need to allocate memory buffers for the client to draw in which means using FFI bidings for EGL and DRM. It appears that you also need to use libwayland for allocation 0 . Other than that you could write the protocol implementation in CL.

              But more importantly what I’d really like is a desktop in CL