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

Separating the Wayland compositor and window manager

isaacfreund.com

Post reply on HN
Print view View original

111–120 of 228 posts

Re: Separating the Wayland compositor and window manager

#111

Post by bandrami »

fc417fc802 wrote: post #108
bandrami wrote: post #102

As predicted, we will re-invent X11 one feature at a time. Maybe someday soon a Wayland window will be able to know its own screen position.

Last I checked the idealists weren't even willing to commit to a virtual 2D rectangular grid of pixels of arbitrary width and height. I think we'll be waiting a while (or more likely using a soft fork of the spec).

Ah, but now instead of one old difficult-to-maintain way of allowing an application to draw on a rectangle on the screen, we have five (and counting!) new and somewhat incompatible ways to do it. Progress.

Re: Separating the Wayland compositor and window manager

#112

Post by thayne »

stainlu wrote: post #107

[flagged]

> If Sway, Hyprland, and others each implement their own WM separation protocol

I think that's pretty unlikely. The smaller compositors actually collaborate fairly well, and if sway, hyprland, niri, KDE etc. decide to implement this, I think they will probably work with river to create a standardized protocol that works across compositors. That has happened before. Hyprland is maybe more likely to do their own thing than the other, but if a standardized protocol caught on I think they would follow that.

Gnome though... I don't think there is a great chance they implement something like this even if several other compositors implement a standardized protocol for it.

Re: Separating the Wayland compositor and window manager

#113

Post by elfalem »

SilentM68 wrote: post #33

Insightful article. I don't recall ever viewing an easy-to-follow lesson, tutorial or book for that matter that clearly explained the various components of a Linux Desktop environment. Always had to follow complicated and obscure guides to do this and that, when solving issues, but seldom did any explain their functions clearly.

Same. This was the first material I came across that clearly and concisely explained DEs in a way that just clicked immediately.

Re: Separating the Wayland compositor and window manager

#114

Post by yjftsjthsd-h »

hparadiz wrote: post #51

Lots of weird misinformation in the comments here. Wayland doesn't choose anything. It leaves the compositor to decide where to position a window and whether or not that window receives key presses or not. The program can't draw wherever it wants or receive system wide keystrokes or on behalf of another program. When appropriately implemented the screenshot system is built directly into the compositor. It's an API th…

> Unfortunately not every compositor implements this.

That's kind of a big sticking point. When GNOME, KDE, and eg. Sway all have different screenshot APIs, the (eco)system doesn't work.

Re: Separating the Wayland compositor and window manager

#115

Post by yjftsjthsd-h »

em-bee wrote: post #95
hedora wrote: post #84

Traditionally, X11 didn’t have compositors, and didn’t need the extra round trip wayland exists to remove. I wonder if there’s space for a project like xlibre (or x.org, if it were revived) to update the x11 protocol to fill whatever gap compositors were meant to fill. For what it’s worth, I’ve been moving all my machines to lxde. Apparently, I accidentally switched back to a compositor free desktop without noticing.…

you are looking for https://en.wikipedia.org/wiki/Compiz note that compiz is also a windowmanager, so already then compositor and window manager were one unit.

The compositor and window manager could be one unit. But you can also just slap picom on with any other window manager and that's fine.

Re: Separating the Wayland compositor and window manager

#116

Post by somat »

WhyNotHugo wrote: post #64
wild_egg wrote: post #19

I've never used a system with Wayland (been on i3 for ~15 years) but every time a project like this comes up, I have to wonder why Wayland is even a thing. So many hoops to jump through for things that should be simple. Sure, X11 has warts but I can make it do basically anything I want. Wayland seems like it will always have too much friction to ever consider switching.

My reason for switching from i3 to sway (about 8 years ago) is DPI support. High DPI is a pain in Xorg, and essentially impossible with heterogeneous monitors. The migration was a one way thing. Lots of things are smoother and simpler, and not having to ever again touch Xorg.conf has improved my quality of life. To this day, I still have different monitors with different scale factors.

The funny thing is that X11 can actually do heterogeneous dpi and Wayland can't.

Unfortunately you will never find yourself in a situation to actually use a mixed dpi X11 setup (you lose your homogeneous desktop) and Wayland is better at spoofing it (for whatever reason fractional scaling works better in Wayland).

http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/

My favorite quote from that writeup.

"If you think this idea is a bit stupid, shed a tear for the future of the display servers: this same mechanism is essentially how Wayland compositors —Wayland being the purported future replacement for X— cope with mixed-DPI setups."

Re: Separating the Wayland compositor and window manager

#117

Post by yjftsjthsd-h »

hparadiz wrote: post #91
Asooka wrote: post #71

Earlier quoted context omitted.

It is 18 years old (started in 2008 IIRC) and just now approaching something usable. So on the one hand it is a really old project whose original design considerations became obsolete a decade ago - I remember people were very bothered by the performance loss of needing several process switches with the X11 damage model in order to push an update to the screen, but on today's multi-core hardware that is basically fre…

It's biggest hurdle is having to explain even to tech people on HN that it's actually a good idea to have a UI where a user can approve a screen sharing request. You'd think for folks that claim to care about security that'd be a prime concern. It really is so weird how difficult that is for people to grasp. The implementation is likewise not complicated. Seriously how hard is it to draw a box selector and show an ok…

If everyone appears to be missing something that's so easy to understand and implement, perhaps they're not missing it. They could have a different security/threat model than you're using. They could be expressing frustrations with being forced to manually approve something every time. They could be hitting dumb bugs in the implementation. There could be different people clamoring for more security and less intrusive security.

Re: Separating the Wayland compositor and window manager

#118

Post by hparadiz »

yjftsjthsd-h wrote: post #117
hparadiz wrote: post #91

Earlier quoted context omitted.

It's biggest hurdle is having to explain even to tech people on HN that it's actually a good idea to have a UI where a user can approve a screen sharing request. You'd think for folks that claim to care about security that'd be a prime concern. It really is so weird how difficult that is for people to grasp. The implementation is likewise not complicated. Seriously how hard is it to draw a box selector and show an ok…

If everyone appears to be missing something that's so easy to understand and implement, perhaps they're not missing it. They could have a different security/threat model than you're using. They could be expressing frustrations with being forced to manually approve something every time. They could be hitting dumb bugs in the implementation. There could be different people clamoring for more security and less intrusive…

Honestly most people are just being lazy about it. You don't even need to prompt the user if you wanna allow everything by default. You just need to implement the screenshots, screensharing, and hot keys APIs. All 3 are super simple.

Re: Separating the Wayland compositor and window manager

#119

Post by fc417fc802 »

bandrami wrote: post #111
fc417fc802 wrote: post #108

Earlier quoted context omitted.

Last I checked the idealists weren't even willing to commit to a virtual 2D rectangular grid of pixels of arbitrary width and height. I think we'll be waiting a while (or more likely using a soft fork of the spec).

Ah, but now instead of one old difficult-to-maintain way of allowing an application to draw on a rectangle on the screen, we have five (and counting!) new and somewhat incompatible ways to do it. Progress.

Don't worry, I will personally see to solving this problem once and for all. https://xkcd.com/927/

Re: Separating the Wayland compositor and window manager

#120

Post by twiclo »

kyorochan wrote: post #61

River was really great even before this split, so I'm very excited to see what happens in the space in the future. I switched to Niri while waiting for it to happen, and I'll probably switch back at some point. If you were an Xmonad user I feel pretty confident in saying River is the Wayland WM for you.

I'm still on Xmonad mainly because I've only tried hyprland and it couldn't handle the master/slave stack the way xmonad does. On River, when I create a new window will it be inserted above the current selected window even if the current window is the master?

Also, when it was split up what did he call his window manager? Looks like the River repo is just for his display server/compositor

Post reply on HN