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
Hyprland: A dynamic tiling Wayland compositor
31–40 of 86 posts
Re: Hyprland: A dynamic tiling Wayland compositor
#32It'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.
Re: Hyprland: A dynamic tiling Wayland compositor
#33This 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.
Re: Hyprland: A dynamic tiling Wayland compositor
#34The 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…
> "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.
Re: Hyprland: A dynamic tiling Wayland compositor
#35Earlier quoted context omitted.
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 will never be a popular way to use Wayland because its just a worse design.
Re: Hyprland: A dynamic tiling Wayland compositor
#36The 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…
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.
Does not phoc / phosh work like that?
Re: Hyprland: A dynamic tiling Wayland compositor
#37Earlier quoted context omitted.
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...
Re: Hyprland: A dynamic tiling Wayland compositor
#38The 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…
> "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.
Re: Hyprland: A dynamic tiling Wayland compositor
#39The 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…
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.
Re: Hyprland: A dynamic tiling Wayland compositor
#40I'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.
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.