Hyprland: A dynamic tiling Wayland compositor (opens in new tab)

I'm the author of the mentioned blog post. The situation changed a little bit since I published the post, which is that wlroots finally gained upstream the scene graph API, which abstracts away a lot of the painful parts of compositor development, mostly the parts about rendering windows and damage tracking.

It is hard to quantify how much buggy, or less buggy, are "amateur" Wayland compositors compared to their X11 counterparts. While it is true that a Wayland compositor programmer has to code by hand a lot of boilerplate as I explained in the article, now that the absolute ugliest yet-still-essential parts have been abstracted away in the scene graph API (before, if you didn't implement damage tracking, you had to basically say goodbye to your laptop's battery), besides the other ugly yet-still-essential parts that are already the entirety of wlroots, now compositor writers have the sweet-spot where they can integrate the special behaviour their compositor is all about with nicer graphics, rendering, input handling etc. IMO, this actually leaves room for less bugs, and all around a much better, and stable, experience, than what one would get with an X11 WM + a X11 compositor on top.

And, looking at this compositor, Hyprland, it looks like just that. It's a nice dynamic tiling compositor, but it also has some very slick graphics, animations, config system. Looks like nothing I've seen before in the ricing space. And by quickly looking through its source code, it looks like it benefited massively from wlroots and from the scene graph API, plus all the other Wayland protocol extensions that are implemented ready-to-use in wlroots. Great work from the community!

There were some mis-steps with Wayland being too light [0] - but we're entering an exciting new era where people start experimenting in the graphics space again. wlroots might be enough, or there might be a few attempts to get the supporting libraries right. But it'll be solved in time.

[0] There was a subtle mechanism-not-policy error where they made screenshots impossible without some back-channel being available. In hindsight, there should have been mechanisms for sharing buffers at the protocol level. "Can't share" turned out to be a forced policy, and the wrong one.

On the other hand, there is nothing in Wayland that prevents anyone from writing a compositor that splits off some window management tasks to a separate process. Afaik nobody has bothered to do so yet, but if there is demand then it could be done. Or maybe there isn't that much demand for such thing.

>The problem with "alternative" Wayland compositors is that so much more functionality is pushed into the compositor under the Wayland architecture compared to window managers on X11.

That comparison is a bad one to make. Compared to just a window manager, that's correct. But you have to compare Wayland compositors to X11 compositors and for that it's about the same amount of work. Either one expects you to bring your own rendering because that's the main benefit of writing a compositor.

It also might make sense to compare X11 window managers to compositor plugins. The reason people seem to prefer wlroots is precisely because it offers more power and more control over the just writing a window manager.

This compositor, like most Wayland compositors, uses the wlroots library, so most of that tedious work is already handled for you.

Yeah, but wlroots is taking the role of Xorg there, leaving WM writers to mostly just write the WM

> "With Wayland, you handle everything, even with wlroots."

The observable effect of this is that the long tail of niche projects like X11 window managers, custom toolkits or small applications (that don't carry around extremely heavy dependencies like GTK/Qt) gets decimated. The assumption that this is done on purpose is plausible.

The article at the link you posted is about the Cardboard WM.

Shoutout for Cardboard, an awesome Wayland compositor and a rare example of Scrolling Tiling window management.

https://gitlab.com/cardboardwm/cardboard

So just push all that shared logic into a library that alternative Wayland compositers can all use.

eg. wlroots

An X11 window manager is more akin to a gnome extension than a proper window manager. Just because writing such a plugin is easy shouldn’t make our expectations all that different.

And frankly, for putting together a window manager the proper choice of action is extending an already existing compositor.

> wayland compositor is still a lot more work than writing

If you speak about a probably working one instead of a toy one the difference between X11 and wlroots isn't that big AFIK.

It's just that with X11 you could create a toy compositor with very little lines of code and that's not possible anymore.

But then toy compositors also kinda don't matter in the grater picture so it's not really a problem.

I'm not a fan of animations myself, though I think it could be somewhat useful with a tiling WM to help maintain (for lack if a better word) your orientation. Sometimes a new window will open and move the other windows around and get resized unexpectedly, or you'll move a window and lose track for a split second. Animation would show you where everything gets put so you don't have to reorient yourself. Not a very common issue, but I could see animation helping there.

I want my systems functional, efficient, snappy.

One of the first things I do on a new device is to disable animations and similar "eye candy". On Gnome it's hidden, but can be changed with gnome-tweek-tools ; on Android it's hidden too, in the developer options that you have to unlock (7 taps on build number).

In both cases, those animations easily lose frames and are distracting, without talking about the frivolous power spending on portable devices, but they are enabled by default and not easily removed.

It bugs me to jo end that wrong priorities seem to apparently be the norm.

Personally a huge fan of the animation showcase, I'd be willing to take a latency hit because I find it much easier to keep track of. Obviously I overcame any such issues in order to get use standard TWMs, which I do just fine, so idk if I'd still appreciate how they feel interactively? But I'm glad to see the amount of customization available within them, maybe I'd just speed them up or otherwise adjust the curves.

I dislike almost all desktop animations, except for sliding between virtual desktops, and an animated zoom-out to view all desktops. Particularly the first; having an animated slide between virtual desktops really helps me form a spatial feeling for where windows on different desktops are. But miss me with animated minimizing (magic lamp is the worst!), wobbly windows, etc. That sort of eyecandy is very distracting, I used it for a few days when I first tried Beryl, but never since.

Having a compositor that does desktop zoom is very nice too, although not quite in the same class of features as those eyecandy animations. Frustratingly, Kwin won't let you set a mousewheel keybind for this zoom effect, a senseless limitation. You can get around this with xbindkeys though, using config like this:

    "qdbus6  org.kde.kglobalaccel /component/kwin invokeShortcut view_zoom_in"
      Mod4 + Super_L + b:4
    "qdbus6  org.kde.kglobalaccel /component/kwin invokeShortcut view_zoom_out"
      Mod4 + Super_L + b:5

I have no clue how you'd fix this if you're using Kwin/Wayland..

For anyone like me who uses macOS and also dislikes the genie minimize effect, you can change it[1] and/or change/turn off a huge variety of animations[2].

1: https://macos-defaults.com/dock/mineffect.html#set-to-genie-...

2: https://apple.stackexchange.com/a/63477

With high refresh rate displays, Im excited to see what 0.3s duration animations look like. I have hopes a small dose of fluidity inside the fast, snappy tiled experience can add some understandability, provide some good context, while not slowing down the flow. Not, like, in compiz, making really slow navigation systems, just adding some continuity to current paradigms.

#swaylife

I sorely miss tiling WMs when I use MacOS; Amethyst and yabai just seem to big out all the time, lose track of windows, get confused by native tabs, and deal poorly with windows that force maximum/minimum sizes. I've concluded that MacOS's window model just really doesn't mesh with tiling. My current solution, after much experimentation with tools like Rectangle, Hookshot, and Spectacle, is to use Swish[1]. It feels sort of like an inside-out version of how I use Sway on linux. With Sway each window that I open is tiled onto the current desktop, then I re-balance the split or reposition the window with my mouse, and set the window to float if it doesn't cooperate. With Swish each window opens as floating, but by swiping on its title bar I can tile it into whatever position I want. This defaulting to floating works better on MacOS where the frequency of uncooperative windows is much higher than on linux. The killer feature of Swish for me is that it keeps track of the grid you make by swiping windows into place and maintains it even when you resize or reposition windows relative to one another, much like i3/sway. It's still quite frustrating though that I have to pay $16 for an app to make window management bearable. This is a basic OS feature that I've come to take for granted.

1: https://highlyopinionated.co/swish/

Check out https://github.com/ianyh/Amethyst I’ve been using it for years and it makes MacOS window management a dream.

Try yabai.

https://wiki.hyprland.org/Getting-Started/Installation/ has some relevant info relating to this

> Arch, NixOS and openSUSE Tumbleweed are very supported. For any other distro (not based on Arch/Nix) you might have varying amounts of success. However, since Hyprland is extremely bleeding-edge, distros like Pop!_OS, Ubuntu, etc. might have major issues running Hyprland.

and

> This project is under development and is constantly changing.

It’s not practical to expect that they will support every distro from the get-go, when they are actively developing it.

It uses dynamic tiling rather than static tiling meaning more versatility how specific desktops get arranged such as bsp, tree, or even custom arrangements

I'm just giving this a try and with xdg-desktop-portal-hyprland (their fork of the wlr portal) I get perfect screensharing in Google Meet using pure Wayland.

That alone is interesting enough to get me to look at switching..

had that issue as well but I found that enabling a couple optimizations fixed them all on my laptop. I created an aur package for it hyprland-opti-git

Yes. All effects are entirely optional