Hyprland: A dynamic tiling Wayland compositor
hyprland.orgThe 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. So it's a ton more work to write a Wayland compositor than an X11 window manager, and most of it is tedious boilerplate that almost certainly has nothing to do with your motivation for writing a new compositor in the first place. This in turn affords many more opportunities to introduce bugs, missing functionality etc. I trust "weird" compositors much less than I trust "weird" X11 window managers - it's more like using an alternative Xorg than an alternative WM.
"...there is still a lot of boilerplate involved in writing a compositor, much more than for an X11 window manager, namely setting up your own rendering code, registering and storing input devices and screens in your own data structures, passing input events to windows, calculating bounds for bars and other overlays (courtesy of layer-shell) and others. X11 handles all of this for you..."
https://tudorr.ro/blog/technical/2021/01/26/the-wayland-expe...
<edit> Several people mentioning wlroots. I can't say I've ever attempted it myself, but if you take a look at the blog post above, the author is very clear on the fact that even with the benefit of wlroots (which they highly praise) writing a Wayland compositor is still a lot more work than writing an X11 window manager (which they have also done, so they are something of an authority). wlroots doesn't abstract everything away, it just gives you a bunch of useful tools.
"With Wayland, you handle everything, even with wlroots."
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.
No, that wasn't a mis-step and it wasn't the wrong policy. Wayland is primarily concerned with taking buffers and telling the GPU to put them on the screen. Buffer sharing between clients is more concerned with the opposite: taking GPU buffers and turning them back into CPU-readable pixels so software can do arbitrary processing on them. Those are two very different concerns.
And because screenshots are a privileged operation, this will always need to go through a back-channel anyway to handle the security aspect. Otherwise you'll end up with a repeat of X11 again where any Wayland client connected to the server can scrape the screen at all times. So for desktop use there's really no reason to ever put it in a Wayland protocol. The design from the beginning was to keep privileged operations (like screenshots and input grabs) out and that still holds true now.
That is the view they took; but that view involved a decade-long process to get a Wayland ecosystem to where we could reliably screenshot the full screen. Still isn't possible in Debian Stable if I recall correctly. Wayland is the future, but lets not put on too brave a face. The design for accessing the composited output was bad and it fell over in practice.
There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop. If someone wants to "install Wayland", technically they might end up having to research which framework they have to work with to make a Zoom call and screen share, which could be incompatible with Google Meets and screen sharing. Indeed, that dynamic will force centralisation on a specific set of libraries just like X used to with drivers - for no particular reason other than they didn't feel like scoping out the original specification a little more practically. If all the Wayland compositors are going to be expected to use the same library, they may as well have included it as an appendix back in '08 and saved all the mucking around in the mean time.
This is hardly the end of the world and I do think the people involved in Wayland made a good attempt. But hindsight is 20/20 and the wart is now quite obvious.
>Still isn't possible in Debian Stable if I recall correctly.
It depends on the app. Chances are older apps needs to be updated to use the portal.
>There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop.
No, there's only one way. Use the XDG screenshot portal. It's not a library, it's a standard API the desktop implements.
>for no particular reason other than they didn't feel like scoping out the original specification a little more practically
There was a reason. They didn't scope it out because they couldn't. Privileged operations need to be implemented using OS-specific security facilities. There's no way to make this work correctly just with Wayland. On Linux it needs a sandbox, and those are very different in scope and design from a window system.
>But hindsight is 20/20 and the wart is now quite obvious.
No, there's no wart. Or rather, if there is a wart, it's on the OS itself and how it does security. Linux didn't have a way to do this kind of sandboxing before, so someone had to invent that too. Efforts to hack sandboxing into X11 (see Qubes OS) have run into these same problems.
Now I'm certainly no expert in this area (and I'm sure it shows) but xdg-desktop-portal was built to support Flatpak and is linked fairly closely to PipeWire.
"The protocol is great, you just need to rebuild your Audio/Visual stack to support it" is certainly a reasonable take when dealing with something as weird as X. But, and I say this with a certain level of sympathy, bit it showcases a deep inflexibility in the design of Wayland.
Taking screenshots is not that hard by default. I'm very glad that someone is taking on the mammoth task of improving the linux graphics stack, but it is obvious that they designed screenshots out of the system then had to work for a decade to design them back in by reworking the way multimedia is done, and de-facto we're only going to be able to use Wayland in conjunction with XDG standards making sure that implementing the light protocol in a light compositor is a mistake. That isn't the end of the earth, it is no worse than what we do now - but it is a glaring weakness in the Wayland protocol that could have found a way to be usable from 2008 -> 2018.
It's not a weakness or inflexibility in the Wayland protocol. There's no way to make it work there. They had to rework the way security is done, and that's a much bigger task that touches lots of other parts of the OS. I keep saying this but you're not listening to me. Why?
Yes, if you want to use a secure system then you need to only go through secure APIs. If you cut out security in the name of making a "light" compositor then you just lose the ability to run sandboxed apps correctly, so it's crippling your desktop for no good reason. The XDG portal was built as a secure API to support Flatpak but it doesn't actually need Flatpak. The compositor is what needs to implement it so any sandbox can use it.
Like many other things (including, originally, copy-paste), you were supposed to use your desktop environment's support for this over to-be-specified D-Bus API
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 blog post mentions Wayfire, which has a plugin architecture, so not separate processes but an abstraction boundary at least - which is the more important thing.
River does that for the windows layout https://github.com/riverwm/river
Does not phoc / phosh work like that?
>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.
It's not a bad comparison to make when people are writing entire new compositors just to provide, say, a tiling experience - exactly the way they used to write window managers. I understand you're trying to be "fair" to Wayland here but the fact is there is a lack of an abstraction boundary where there used to be one. Maybe that abstraction boundary can be reinstated by a well-written compositor with a plugin architecture, but that isn't standard the way the window manager interface is (unless you can persuade everyone to use that one compositor).
I think you're missing that authors of tiling window managers don't actually want to go back to the X11 way of doing things. They don't want to write a basic window manager or a plugin. That abstraction boundary is bad and it's extremely limited. That's why the X Composite extension was created in the first place. There was a chance to go in the opposite direction with Wayland. People did actually make plugin APIs but they never became standard, few developers wanted to use them. Instead wlroots became popular because it allows a lot more power and flexibility over compositing. The compositing approach is what allows Hyprland to have those nice transparencies and animations. So it's not that I'm trying to be fair to Wayland, I'm actually trying to be fair to X11 compositors. You're skipping that whole step that happened in the mid-2000s when you make your comparison. People wanted to make compositors all along.
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
I'm just wondering how long it'll be until someone uses wlroots to write a client/server architecture like Xorg...
It already exists and its called xwayland. Most wayland compositors also have X11 WM inside them...
You misunderstand: I'm not talking about the X protocol, I'm talking about some new all Wayland thing just so window managers can be separated from the other things you'd otherwise have to implement.
Yes and ironically Xwayland is that, but you probably want something like Arcan
I think Mir can do that
It will never be a popular way to use Wayland because its just a worse design.
> "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.
Plausible, but not realistic or actually happening, because there's nothing at the protocol level that prevents the long tail of small compositors, toolkits or applications from implementing a Wayland backend.
> there's nothing at the protocol level that prevents the long tail
Severe over engineering, unstable interfaces, massive boiler plate and huge development overhead is preventing the long tail "at the protocol level".
As example: Compare the Wayland "Hello World" [1] with X11 "Hello World" [2]. If you want to add the ability to take screenshots it gets exponentially worse. (Also the Wayland version is not even capable to render strings.)
1.: https://github.com/emersion/hello-wayland/blob/master/main.c
>Severe over engineering, unstable interfaces, massive boiler plate and huge development overhead is preventing the long tail "at the protocol level".
No, all those can be solved with client libraries. X11 had Xlib and the other client libraries. Those X11 libraries don't make sense in Wayland, but the client libraries that stayed relevant (freetype, cairo, etc) can still be used.
>If you want to add the ability to take screenshots it gets exponentially worse.
No, in both modern X11 or Wayland, you should use the same API for screenshots: the XDG screenshot portal.
>Also the Wayland version is not even capable to render strings.
Sure it is, but you have to use client-side rendering. Client-side rendering is also the norm in X11, since decades ago when Xft was released as another one of those client libraries. That X11 hello world is short because it's using obsolete APIs.
> No, all those can be solved with client libraries.
There is no easy way to open a Window and render a string. Period! You either need to write it yourself completely (as OP stated) or you can use Gtk/Qt or other heavy weight "client libraries" (cairo and freetype do not create Wayland windows and therefore are not applicable here).
Look at the code again! If you really think that the code at [1] is in any way a great solution as compared to [2] we are going to disagree.
> No, in both modern X11 or Wayland, you should use the same API for screenshots: the XDG screenshot portal.
ZERO screenshot apps on X11 use XDG screenshot portal, they all use XGetImage(). Mainly because the assumption that a dbus-daemon is always running everywhere is mostly false. Also XDG screenshot portal is simply not a good solution. It is cumbersome to use, contains tons of edge-cases and pulls a dbus dependency for something that could be solved much simpler with onboard OS-functionality without the need for extra daemons and weird binary protocols
> Client-side rendering is also the norm in X11, since decades ago when Xft was released
Besides the point, but you are still wrong. Xft does server-side rendering via XRender. The cache is rendered only once on the client but that's a technicality, spline tessellation was supposed to go into the server but Keith Packard had more important things to do at the time.
>There is no easy way to open a Window and render a string. Period!
Yes, there is. Use a client library. That's what they're for.
>You either need to write it yourself completely (as OP stated) or you can use Gtk/Qt or other heavy weight "client libraries"
This is exactly the same as in X11. Remember Xlib is one of those heavy weight client libraries. The X11 example you showed uses Xlib.
>Look at the code again! If you really think that the code at [1] is in any way a great solution as compared to [2] we are going to disagree.
I don't think either of them are great. I'm saying that's comparing apples to oranges.
>ZERO screenshot apps on X11 use XDG screenshot portal, they all use XGetImage().
They shouldn't. Like most parts of X11, XGetImage is an obsolete API. You don't want to use that in modern clients.
>Mainly because the assumption that a dbus-daemon is always running everywhere is mostly false.
No, dbus is used by basically all modern desktop environments on Linux. If you don't have dbus available you're going to have a lot more problems running normal Linux apps than just dealing with the differences between X11 and Wayland.
>Also XDG screenshot portal is simply not a good solution. It is cumbersome to use, contains tons of edge-cases and pulls a dbus dependency for something that could be solved much simpler with onboard OS-functionality without the need for extra daemons and weird binary protocols
X11 is also one of those weird binary protocols that isn't onboard OS-functionality and has more edge-cases, so according to this XGetImage isn't a good solution either.
>Xft does server-side rendering via XRender.
No, you've got rendering mixed up with compositing. With Xft, the rendering of font data to pixels is still done in the client. XRender, despite the name, is frequently only used to composite surfaces together. That's doing the same thing that Wayland is doing.
>XGetImage is an obsolete API. You don't want to use that in modern clients.
How is obsolete and what makes XDG portal a better option?
X11 APIs have no security and they don't work in Wayland. Either one of those reasons is enough to avoid using them.
Aside from that, it's the slowest and worst possible option in X11 because it copies the pixels into the socket. To handle large images you want to at least use MIT-SHM. XGetImage should only be used as a fallback. Or better, just don't use X11 APIs at all.
That’s just optimizing for the wrong thing. Why should it be easy to write from zero a “hello world” window? Where would you go from there, what’s useful about that? Should it also handle inputs, redraws, widgets, layouting?
The LXQt project, that has a Wayland branch (sometimes called LWQt) actually uses mutter (the GNOME compositor) and --at this point-- not KWin to for its compositing needs.
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.
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've never liked animations in interfaces like this. It was fun to play with when Compiz was new, but it doesn't make the tool any more useful or pleasant for me to use. At least it's not as bad as the OSX "magic lamp" minimize.
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.
Yeah they can be helpful in such cases. I used Gnome for a while and although I liked the overview animation, it was too slow for my taste and you needed an extension to speed it up, so I just disabled them. I see that Hyprland allows you to configure this OOTB though.
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.
Note: when disabling animations on GNOME, a noticeable delay seems to remain before the alt-tab switcher appears.
I don't remember which extension I use to work around that; maybe this one: https://extensions.gnome.org/extension/1317/alt-tab-switcher...
I like gsettings. You can just put the calls in a script once and call it whenever needed. You can access everything from there. You can search for relevant keys from the terminal or with dconf editor.
If implemented well it shouldn’t cost too much energy, it is basically interpolating a value and redrawing it a few times with the GPU.
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 also see no problem with animations, but they should be “interactive” as in ios app switch gesture — that is, they should be as fast as the movement itself, and should be reversible, etc.
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:
I have no clue how you'd fix this if you're using Kwin/Wayland.."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:5For 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-...
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'd love to take advantage of this incredible tool in MacOS. Managing windows on MacOS is quite a challenge.
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.
Actually, if you're interested at all, I just, after literally months of reading about this, found a pretty sick solution.
Have you ever heard of Phoenix? https://github.com/kasper/phoenix/. Despite googling around for this exact topic, with 3.8k stars I had never heard of it. Apparently someone has created slim, JS scriptable interface that is basically tailor made toward creating your own tiling WM. I just installed it and loaded one of the examples: https://github.com/nik3daz/spin2win. And what it does is basically ignores the built-in spaces and creates truly virtual desktops by just hiding and resizing windows. And it works pretty well. The response time between switching "desktops" is basically instant.
I had not heard of Phoenix, and it looks interesting. Though I doubt I would be able to do a better job of reimplementing sway/i3 in Javascript than the folks working on yabai have managed.
So, you don't have to. Check out that spin2win "example" I linked, it's really less of an example and more of a pretty fleshed out implementation of XMonad. I don't really know javascript/TS at all and I was able to get it running with a few tweaks in 20 minutes or so. Phoenix is super intuitive.
I'll admit it is a little bit janky (which the author admits/warns about). But it seriously does work better than yabai. This config (using Phoenix) basically abandons the native "Spaces" functionality and does everything by just maintaining an internal window state and moving windows around fast. So you don't have to disable SIP (a big thing for me, since I want to use this at work). I'm seriously kind of blown away, this is miles better than apps that people are paying for, and it was just sitting here in this guy's github fork.
It is super disappointing this is the best that Mac can do though. There is no reason there shouldn't be a mostly-native (ie, less janky) tiling wm solution on the platform.
Well that's the thing, I don't want an xmonad replacement; I'm not a fan of automatic tiling. I much prefer manual tiling a la i3. I looked through the Phoenix examples and didn't find something that worked how I wanted, so I'd be left implementing it myself. The reimplementation of Spaces by hiding/unhiding windows does sound like a nice trick that Amethyst and yabai should adopt though.
I've been using MacOS for awhile and this is likewise my one true gripe. I've played around with amethyst and yabai and also find them just a little too shaky to rely on. I miss the rock solid nature of i3/bspwm. And trying to script my own functionality with Hammerspoon or BTT has been an exercise in frustration. I'll give Swish a shot with this recommendation.
However I'm not sure Swish solves the big benefit of i3/bspwm for me, which is the lightning-quick virtual desktop and "send to desktop" functionality of a tiling WM on linux. Having two apps open side by side is useful, but not quite as useful as having two apps open full screen on virtual desktops 1 and 2, and the switch between them being totally instantaneous.
> lightning-quick virtual desktop
I recall that yabai can achieve this with SIP disabled. It somehow injects code to disable the Space switching animation, so hotkeys to switch Spaces become instant.
Check out https://github.com/ianyh/Amethyst I’ve been using it for years and it makes MacOS window management a dream.
Try yabai.
It's a shame that they refuse to use a versioned release of wlroots. It makes packaging this needlessly difficult (or impossible, depending on distribution policy).
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.
Any advantages over Sway, other than look and feel?
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 thought Sway was based on i3, which is an arbitrary-width tree that can have different display modes per container node in the tree.
Hyperland's wiki only lists "Dwindle" and "Master" layouts, which from the description are strictly less versatile than i3 (and Sway?) in exchange for convenience if those layouts are what you want. Does it even have something as flexible as i3? (and Sway?)
I use the dwindle layout which is similar to bspwm in automatic splitting mode. One advantage is you can drag and drop windows into other nodes, which will be split appropriately, it's surprisingly neat when you have a lot of stuff open. It's easiest to get a feel for the differences by just trying it out or watching some videos of it on r/unixporn
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..
Perfect screensharing meaning you can select individual windows to share as well as the entire screen(s)?
Correct - without XWayland
That works on most wayland compositors nowadays for quite some time now.
I've only ever been able to share XWayland windows - using Chrome under sway
How does Hyprland compare to the Pop!_OS tiling system?
I want to switch, but it's still super glitchy on NVIDIA and waaay too slow on my laptop.
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
This looks beautiful and it's in AUR, so I'm definitely going to try this tomorrow. I've been shopping for a replacement for GNOME because they keep removing features I'm in the middle of my using which is really stressful and I just can't trust them anymore.
Using sway currently, I intend to check it out.
Just so that I know beforehand, can transparency, gaps, animation be turned off?
Yes. All effects are entirely optional