Hyprland is now independent, dropping wlroots | Hacker News Reader

Hyprland is now independent, dropping wlroots

hyprland.org

69 pointstuananh43 comments

Love what Hyprland has accomplished and how it has inspired other multiple projects. Even like in 2021 the only daily driver option for Wayland was Sway.

Edit: can't delete the parent. Reading the other comments about the fiasco regarding CoC, I don't want to support Hyprland unilaterally anymore, still an impressive project on the tech-side, but real life software communities are more than just the tech.

Congratulations! Genuinely impressive achievement. I don't plan to use Hyprland but the amount of work Vaxry and the Hyprland contributors put into the project is pretty inspiring.

Hope you like compiling it yourself. The toxicity of the community means it was refused inclusion by at least one distro (Void Linux).

The toxicity of the Void and Freedesktop community right?

Anyone switched from sway that might comment on their experience?

Have not tried Hyprland but on three separate occasions with three different machines I could never get Sway working. One got close but it would constantly crash.

Got an nvidia gpu in that machine?

The Sway author has strong opinions about nvidia (historically warranted), so you need to specify a magic flag (now --unsupported-gpu, previously --my-next-gpu-wont-be-nvidia).

That's silly, and reason enough just to stay away from it. I don't like when developers try to evangelize their opinions through things like configuration variables. It's quite childish to me.

But yes, that's probably it.

Again, historically it was warranted because Nvidia had their own strong opinions in their proprietary closed-source driver, and hardware acceleration in Wayland just straight up didn't work with said driver for many years because Nvidia was trying to push their own alternative [0], up until 2021 when they finally caved [1].

I agree that the naming of the command-line flag was childish, but I think it was reasonable to refuse to be strongarmed into doing unpaid work to support Nvidia's end-run around standards that all the other players in the space adopted.

[0] https://www.phoronix.com/news/Streams-vs-GBM-Toolkits

[1] https://www.phoronix.com/news/NVIDIA-495.44-Linux-Driver

Hyprland has way more features than Sway. There's 1:1 touch gestures, animations, and per-window screen sharing. Also there's all kinds of tiling configuration available, which allows Hyprland to do manual and/or automatic tiling.

Sway's lack of features is also its advantage, because it's been the most stable and consistent window manager/compositor experience I've ever had on Linux (X and Wayland). Hyprland sometimes has its bugs, which does make sense given how young and fast-moving the project is.

I would have never tried it without having installed Garuda on a couple boxes recently. It was the first time I've seen all the ricing done correctly. I've never been able to fully replicate the configs done by YouTubers or /r/unixporn, something always didn't quite work, usually fonts or the status bars or color themes. Garuda with hyprland is pre-riced and is extremely fast. I could absolutely notice lower latency in the console. I'm definitely going to use it more.

I've used i3 and then sway since a few years, never had any problems (nothing I remember at least).

Then I tried out hyprland, and I had multiple crashes a day, and not really saw any benefit compared to sway. I also needed to disable all of the animations which are enabled by default, because they were nauseating and made everything slower (compared to the snappieness of sway, still faster than macos/windows).

I would have probably invested some time into debugging the issues, if I had seen any reason why I would want to use Hyprland over Sway.

After a few weeks I switched back to sway, and never felt the urge to try it again.

I started with hyprland when I switched my desktop from windows to arch recently (june) and moved to sway. I ran into bugs and behaviour I don't like:

- Having two monitors and turning them off (either physically or through dpms) shifts all workspaces to the last monitor that is on, even if it's on for a split second,

- Turning off monitors (physically/dpms) caused waybar to crash.

I don't have those issues on sway, so I'll stick with it until hyprland matures a little more.

I've given hyprland two tries. The first time it was exceptionally laggy and crashed all the time. The second time (earlier this year) hyprland was performing better, but it still had enormous CPU power draw, lagged with disabled animations, for whatever reason had terrible font anti-aliasing (with the same font-config settings as sway). Maybe a full rewrite to this new stack will help, but I doubt it.

How does Hyprland compare to similar software such as Enlightenment? Which seems to be the same sort of thing but for X instead of Wayland.

Not that similar at all other than both having a reputation for being pretty (Enlightenment is almost 30 years old so other WM/DEs have caught up to and surpassed it on that front IMO but it had a reputation for being one of the nicer looking WMs back in the day).

Enlightenment also supports Wayland these days.

Hyprland is a tiling window manager so it is typically compared to things like i3, bspwm, xmonad, etc.

Hyprland is such a masterpiece of technology, cool to see young programmers take on such projects that keep moving oss forward.

It is truly amazing/awesome how many tiling compositors there are in the Linux universe!

Now make a version that is Xorg compatible.

Or not

Cool idea! Make it yourself :)

These things are not window managers you can just port to a different display server. They are themselves display servers equivalent to xorg.

Guess what, XWayland exists.

XWayland is great for applications and useless for anything else; I expect full Xorg compatibility would let you use ex. xdotool

That does not make sense, wayland and xorg are fundamentally different. in X11 everything is global given that its the X.Org server that manages clients while the wayland compositor does most of the X.Org server by itself. This is also why writing a pure wayland compositor from scratch is much harder as you need to rewrite half of the X.Org server but at the same time in contrast to X11 you don't have security holes like a keylogger in few lines of code. In short, xdotool relies on the X11 protocol while a similar wayland app need a support in the compositor itself.

There is some attempts though like: https://github.com/atx/wtype

I don't think that's inherently true; what would prevent someone making a wayland compositor that implemented the X11 protocols for interacting with other windows?

> There is some attempts though like: https://github.com/atx/wtype

I am aware of several of these attempts; so far they all fall flat precisely because wayland compositors tend to not provide enough API surface to actually recreate xdotool et al. entirely (ex. wtype will always blindly type into whatever window is active, it can't provide xdotool's --window option to pick where keystrokes are going).

Look at Hypr bro. Its hyprland but for x11

Reply on news.ycombinator.com