4 ms·

> Wayland multi-seat + idle-inhibition HDR + variable refresh Fractional scaling The move to Wayland is interesting to observe. On first glance it seems that m

> Wayland multi-seat + idle-inhibition HDR + variable refresh Fractional scaling The move to Wayland is interesting to observe. On first glance it seems that moving to Wayland provides a load of burden on DEs that they never had before - and not just because of the work required to transition. And that obviously this is all Wayland's fault. What I think is actually going on though is that we expect quite a rich feature set from a modern DE - exactly as you have listed. We could never do most of this stuff on X, but Wayland enables it and then follows a load of work to get it all going. In an ideal world there would be a nice clean abstraction boundary between compositor and DE so that this underlying work was shared between DEs. Maybe that is possible, but people who know what they're talking about seem to agree that the Wayland approach is the right way to go and I don't know enough to disagree. Plus, it makes some intuitive sense that your DE should know how windows share rendering space.

phkahler 3y ago
>> In an ideal world there would be a nice clean abstraction boundary between compositor and DE so that this underlying work was shared between DEs. Not sure what's ideal about that. With Wayland the DE IS the compositor. There are a lot of benefits to that. I would hope basic compositing is a fairly small amount of code and many DEs could build on that - which I guess would your clean boundary even if it's in the same process.
- rkangel 3y ago
  I think my point is that wlroots is a set of building blocks, rather than a single library. You can't build an unopinionated single library that just takes care of the Waylandness of your DE, that you can build on top of. The compositing and the windowing and the event handling are all intertwined, so instead the best you can do is wlroots which gives you some blocks you can put together in the appropriate way. It makes for complex, significant work for any Wayland DE, with less shared work. I don't think this is wrong - it seems this is the approach we need to get full featured DEs, it's just unfortunate that that's how reality has worked out.

phkahler 3y ago

>> In an ideal world there would be a nice clean abstraction boundary between compositor and DE so that this underlying work was shared between DEs. Not sure what's ideal about that. With Wayland the DE IS the compositor. There are a lot of benefits to that. I would hope basic compositing is a fairly small amount of code and many DEs could build on that - which I guess would your clean boundary even if it's in the same process.

rkangel 3y ago
I think my point is that wlroots is a set of building blocks, rather than a single library. You can't build an unopinionated single library that just takes care of the Waylandness of your DE, that you can build on top of. The compositing and the windowing and the event handling are all intertwined, so instead the best you can do is wlroots which gives you some blocks you can put together in the appropriate way. It makes for complex, significant work for any Wayland DE, with less shared work. I don't think this is wrong - it seems this is the approach we need to get full featured DEs, it's just unfortunate that that's how reality has worked out.