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

41–50 of 86 posts

Re: Hyprland: A dynamic tiling Wayland compositor

#41

Post by sprash »

tadfisher wrote: post #38
sprash wrote: post #34

Earlier quoted context omitted.

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

2.: https://rosettacode.org/wiki/Window_creation/X11#C

Re: Hyprland: A dynamic tiling Wayland compositor

#42

Post by QUrprUd1nCeicw »

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

Re: Hyprland: A dynamic tiling Wayland compositor

#43

Post by QUrprUd1nCeicw »

sprash wrote: post #41
tadfisher wrote: post #38

Earlier quoted context omitted.

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

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

Re: Hyprland: A dynamic tiling Wayland compositor

#44

Post by dathinab »

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…

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

Re: Hyprland: A dynamic tiling Wayland compositor

#45

Post by Izkata »

Cloudef wrote: post #37
Izkata wrote: post #23

Earlier quoted context omitted.

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.

Re: Hyprland: A dynamic tiling Wayland compositor

#46

Post by cies »

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

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

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.

Re: Hyprland: A dynamic tiling Wayland compositor

#47

Post by sprash »

QUrprUd1nCeicw wrote: post #43
sprash wrote: post #41

Earlier quoted context omitted.

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

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

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

Re: Hyprland: A dynamic tiling Wayland compositor

#48

Post by QUrprUd1nCeicw »

sprash wrote: post #47
QUrprUd1nCeicw wrote: post #43

Earlier quoted context omitted.

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

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

Re: Hyprland: A dynamic tiling Wayland compositor

#49

Post by roenxi »

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…

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.

Re: Hyprland: A dynamic tiling Wayland compositor

#50

Post by rektide »

Y_Y wrote: post #6

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.

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