Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hyprland: A dynamic tiling Wayland compositor

hyprland.org

Post reply on HN
Print view View original

81–86 of 86 posts

Re: Hyprland: A dynamic tiling Wayland compositor

#81

Post by tudurom »

dTal wrote: post #11

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. 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…

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!

Re: Hyprland: A dynamic tiling Wayland compositor

#82

Post by idle_zealot »

extr wrote: post #69
idle_zealot wrote: post #66

Earlier quoted context omitted.

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. T…

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.

Re: Hyprland: A dynamic tiling Wayland compositor

#83

Post by forgotpwd16 »

QUrprUd1nCeicw wrote: post #48
sprash wrote: post #47

Earlier quoted context omitted.

> 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 gre…

>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…

>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?

Re: Hyprland: A dynamic tiling Wayland compositor

#84

Post by ccakes »

jpeeler wrote: post #62
ccakes wrote: post #52

Earlier quoted context omitted.

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

Re: Hyprland: A dynamic tiling Wayland compositor

#85

Post by ccakes »

kaba0 wrote: post #68
ccakes wrote: post #52

Earlier quoted context omitted.

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..

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

Re: Hyprland: A dynamic tiling Wayland compositor

#86

Post by QUrprUd1nCeicw »

forgotpwd16 wrote: post #83
QUrprUd1nCeicw wrote: post #48

Earlier quoted context omitted.

>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…

>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.

Post reply on HN