1. 34

  2. 6

    Very small and nice to look at, but keep in mind the context and time in which it was written, and be careful not to base a new wm on this: It uses xlib, not xcb.

    1. 1

      xlib is built on top of xcb. See the xcb adoption page.

      1. 4

        It is, and that simplified the xlib codebase, but that doesn’t matter much to library users. XCB is a very thin wrapper around the X11 protocol. XLib provides a set of abstractions above the protocol. The problem with XLib is that it provides the wrong abstractions. It builds synchronous APIs on top of a fundamentally asynchronous protocol, which means it’s almost impossible to write code on top of XLib that performs well on a high-latency link.

        1. 1

          You’d think this problem would’ve motivated a different design back in the old days, when high-latency links were common, yet everyone used Xlib. What accounts for that?

          1. 3

            I think it is because the problem is greatly exaggerated. There are some specific functions that have the round trip latency problem - XInternAtom, XGetWindowProperty, and querying extensions I know do this… there’s probably more but I can’t think of them right now.

            XInternAtom was particularly problematic in the day, so they moved to XInternAtoms - the batch version and you can do all the atoms you actually need in one go at startup. Problem solved. Extensions not as popular back then, but again, a relatively small number of calls at startup in most programs and not a huge deal. (Higher level toolkits may not use this optimization though, or request a lot more atoms than they actually need, making the problem look worse than it actually is.)

            XGetWindowProperty is used in protocols like copy paste, but that’s in response to specific events and accompanied with data so a little lag there isn’t a big deal…. unless you use a higher level library that treats the clipboard as a whole to be a synchronous event. But Xlib doesn’t do that as a whole, just getting the next chunk.

            So I’d question if xlib is actually the problem in the first place.

            1. 1

              So why was the point of XCB? To spray XML over everything and make names longer?

          2. 1

            What specific APIs would you blame? I just said this in another comment but I can’t think of very many.

          3. 3

            Yes, but (unless I’m very much mistaken) Xlib is supposed to be deprecated, and new applications are to use XCB directly.

        2. 6

          Tinywm and the likes of micro wm for X made me play and plan to make my own micro wm for my needs. After I moved to Wayland, I knew that will never happen with compositor framework. I think this is what I was the most disappointed from when I switched from X to Wayland. No more easy way to create a fun micro wm in a reasonable amount of time.Maybe one day the kind of dumbed down API/lib will land to recreate the opportunities to make that approachable again.

          1. 9

            just use X dude

            1. 6

              I think this is what I was the most disappointed from when I switched from X to Wayland

              Why switch, then?

              1. 5

                Because Xorg isn’t really maintained and X hasn’t reached the place where it doesn’t need maintenance yet so it will suffer bitrot.

                1. 1

                  Maybe it isn’t “really” maintained because it hasn’t yet suffered bitrot?

                2. 3

                  Simply because I am on Fedora with Gnome and Sway as my main drivers for the last five years and when the switch from X to Wayland has been done, that was it. I don’t have strong opinions about X or Wayland (and do not really care to forge one). And my “biggest disappointment” was basically “oh one of your side projects that you never managed to take the time for, it’s a dead end now”. I mean that is a minor grudge and besides that I stopped distro-hoping and using a netbook since a while.

                  Fedora is doing fine and Gnome is useful when someone has to use to my computer, Sway is stable enough to let me play with its config and provide what I look for. I do not want to go back to fiddle with every step of my config or at least not this part of my config files.

                3. 2

                  You could probably write a short compositor if you relied on a support library like WayFire.

                  1. 2

                    Unfortunately, WayFire is based on wlroots which doesn’t support the proprietary nvidia driver. It does support nouveau, but I wasn’t able to get working on my 4 year old card and it doesn’t support anything after the 10xx series.

                    There are no plans to support it either: https://github.com/swaywm/sway/wiki#nvidia-users https://www.reddit.com/r/swaywm/comments/gvk4np/nvidia_support/ This is unfortunate for multiple reasons, but especially because nvidia has something like 75-80% of the desktop graphics card market.

                    For me, this makes Wayland pretty much dead in the water - my desktop is a gaming machine which I also dual boot for development and the primary toolkit for building compositors doesn’t work with many modern GPUs (which you obviously want for gaming) and I prefer to use something that can be used on both my laptop and desktop. If I insist on using wayland, that pretty much limits me to Gnome and KDE which isn’t ideal.

                    1. 1

                      Fair enough.

                4. 4

                  To me, the value of things like Tinywm is as minimum working examples that contain all of the boilerplate, setup, teardown, and basic protocol-wrangling that would be very difficult to obtain by just reading the manuals. Everything starts out working, and I can hack on it from there.