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

71–80 of 86 posts

Re: Hyprland: A dynamic tiling Wayland compositor

#71

Post by falkaer »

Izkata wrote: post #22
crawl_soever wrote: post #5

Earlier quoted context omitted.

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

Re: Hyprland: A dynamic tiling Wayland compositor

#72

Post by dTal »

QUrprUd1nCeicw wrote: post #42
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…

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

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

Re: Hyprland: A dynamic tiling Wayland compositor

#73

Post by sprash »

kaba0 wrote: post #65
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…

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?

[flagged]

Re: Hyprland: A dynamic tiling Wayland compositor

#74

Post by sprash »

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…

[flagged]

Re: Hyprland: A dynamic tiling Wayland compositor

#75

Post by Cloudef »

Izkata wrote: post #45
Cloudef wrote: post #37

Earlier quoted context omitted.

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

Re: Hyprland: A dynamic tiling Wayland compositor

#76

Post by kaba0 »

sprash wrote: post #73
kaba0 wrote: post #65

Earlier quoted context omitted.

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?

[flagged]

That tinfoil hat looks good on you!

What the hell does this have to do with user experience?

Dev experience? Compared to what exactly? You have 10 hello world windows floating around or what are you talking about?

X11 and the whole desktop linux world is a huge vulnerability, not letting a random install script/dev tool become trivially a keylogger is not security theater. vsync is not mandatory, you know that right? It can be controlled by an app, e.g. games can control it themselves. Outside of that, why would you want tearing?!

Worse performance? Is that why embedded systems actually prefer wayland solutions over literally embedding a huge monolith? It has as many functionality as you implement..

I’m fairly sure that a bug in xserver will bring down the whole system. There is nothing inherent in wayland demanding a monolithic approach, you can have a server maintaining connections to clients and a plugin that handles the window management part that can be restarted.

You managed to not have a single valid point, congrats!

Re: Hyprland: A dynamic tiling Wayland compositor

#77

Post by dTal »

kaba0 wrote: post #76
sprash wrote: post #73

Earlier quoted context omitted.

[flagged]

That tinfoil hat looks good on you! What the hell does this have to do with user experience? Dev experience? Compared to what exactly? You have 10 hello world windows floating around or what are you talking about? X11 and the whole desktop linux world is a huge vulnerability, not letting a random install script/dev tool become trivially a keylogger is not security theater. vsync is not mandatory, you know that right?…

>why would you want tearing?!

Avoiding tearing inevitably involves adding latency (the data is ready, render half a frame now or wait for vsync?) Some might consider it worthwhile to give up frame-perfection in exchange for getting as much data to the user as fast as possible; that's valid. Latency isn't just important for games, it colors every interaction we have with the computer.

Re: Hyprland: A dynamic tiling Wayland compositor

#78

Post by QUrprUd1nCeicw »

sprash wrote: post #74
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…

[flagged]

>The Glyphs themselves are rendered only once client side.

That's literally what I just said? The glpyhs get rendered client side and then composited in the server.

>What is your agenda? I truly don't understand.

I don't have an agenda. Do you have to assume everyone has one? Please just take my comments at face-value.

Re: Hyprland: A dynamic tiling Wayland compositor

#79

Post by QUrprUd1nCeicw »

dTal wrote: post #77
kaba0 wrote: post #76

Earlier quoted context omitted.

That tinfoil hat looks good on you! What the hell does this have to do with user experience? Dev experience? Compared to what exactly? You have 10 hello world windows floating around or what are you talking about? X11 and the whole desktop linux world is a huge vulnerability, not letting a random install script/dev tool become trivially a keylogger is not security theater. vsync is not mandatory, you know that right?…

>why would you want tearing?! Avoiding tearing inevitably involves adding latency (the data is ready, render half a frame now or wait for vsync?) Some might consider it worthwhile to give up frame-perfection in exchange for getting as much data to the user as fast as possible; that's valid. Latency isn't just important for games, it colors every interaction we have with the computer.

That's less and less relevant as GPUs and displays get faster. You might gain a trivial amount of latency in certain cases, with specific apps, at the cost of bringing back stuttering. The normal case is always going to be vsync. If your program is hardware accelerated it's not actually rendering "half frames," it draws the whole frame and the tearing you see is just a result of swapping at the wrong time.

What I mean here is the rendering in clients isn't going to change either way, everything is already built to use vsync. Turning it off is more a matter of how many switches the compositor wants to provide for controlling the throttle. Most compositors should have support for fullscreen unredirect anyway, and that gets you most of the way there.

EDIT: A few years ago this blog by Raph Levien sketched out a way to reduce latency without bringing back tearing, you may want to read it. https://raphlinus.github.io/ui/graphics/2020/09/13/composito...

Re: Hyprland: A dynamic tiling Wayland compositor

#80

Post by QUrprUd1nCeicw »

dTal wrote: post #72
QUrprUd1nCeicw wrote: post #42

Earlier quoted context omitted.

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

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

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.
Post reply on HN