Wlroots: wlr_desktop and wlr_view

[ddevault]

Alright, I've come around to this idea. Much of what's currently in rootston (roots_desktop and roots_view) can be moved into wlr. Design concerns:

• This should be able to render any of our shell's views, but also any of the user's custom shells. So wlr_view needs to follow the typical user-implementable pattern (like wlr_output and wlr_backend) and have each of our shells implement it.
• It should support more than just shell-style views. wlr_view needs to be flexible enough (or wlr_desktop needs to provide an alternate mechanism) to support weirder protocols like surface-layers.

[ddevault]

Rationale: it's becoming complicated to make the user manage everything themselves and it will be difficult to unify shell/etc protocol implementations among wlroots-based compositors without having some kind of desktop abstraction. We'll also likely extend the role of the desktop in the future even further, with extra support code for things like optimization (#192).

[ddevault]

Anti-rationale: every piece of the puzzle we implement makes it harder for users to customize the behavior of wlroots. Non-desktop style compositors (like mobile devices or in-vehicle entertainment) will have little use for wlr_desktop, and even though they can just choose not to use it, they will lose out on many of the smaller features of wlr_desktop that would benefit them without subscribing to the desktop paradigm, such as output-wide gfx optimizations.

[acrisci]

One thing I like about the architecture of wlroots is how decentralized it is and how little each of the components depend on each other. It really feels like a "collection of libraries" that the user can put together for whatever use case they need. I think this quality makes it appealing for non-desktop use cases like kiosks and mobile devices because the user doesn't have to spend time pealing back all the desktop functionality for security purposes. I would like to keep those use cases in mind as we move forward with our designs.

From studying the architecture of libweston, one thing I don't like about it is how monolithic it is. It has a very all-or-nothing feel to it so that whatever you make with it is probably going to look a lot like weston. I believe there is still a lot of innovation still possible in window manager design as well as a lot that can be carried over from legacy X11 window managers like awesome, xmonad, and bspwm which all look nothing like weston. One of my early concerns with wayland was my perception that it could not preserve the unixy quality of the community linux desktop experience (although X11 is unixy to a fault). One of my main motivations for working on this project is to help carry this community forward into the wayland era and preserve the diversity of the ecosystem.

So I think we should be careful to do this in the least opinionated way we possibly can. I see the need to unify the shells with common abstractions, but let's keep in mind that the data structures of the view are the primary way that window managers differentiate themselves.

[ddevault]

After spending some time on this, I concluded that I don't think we can implement wlr_desktop in a way that meshes with wlroots goals.

[ascent12]

Makes sense. The more complicated rendering stuff involving buffer damage and buffer age can be added to rootston, and people can just copy it if they want to.