- the client and compositor need both implement this protocol extension
- the client needs to ask the compositor whether it should provide its window decorations
- the compositor needs to cooperate and tell the client that the decorations are server-side
Is that right?
I'm also puzzled by something else now: in Wayland, any access to absolute screen coordinates is considered a security risk. So how can a client provide windows decorations then? The main functionality there is moving the window around, which means setting a new absolute window position after a user interaction. How is this possible when the position is hidden away?
EDIT: if I had read the compositor source code before posing the question, I'd have known that the client merely provides the window decoration as a visual area, but not its behaviour. The move and resize behaviour itself including user interaction is part of the compositor.
> if I had read the compositor source code before posing the question, I'd have known that the client merely provides the window decoration as a visual area, but not its behaviour. The move and resize behaviour itself including user interaction is part of the compositor.
Things get weirder and weirder. So clients are supposed to draw in controls, but compositors determine how they behave‽ What if a client draws a close button, but a compositor doesn't have any such concept? What if a client doesn't draw a close button: how does a compositor expose the ability to close the window?
Either this is poorly though-out (unlikely) or I'm really missing something (rather more likely).
I'm not clear on the precise history, but I get the sense that Wayland was largely originated out of the Gnome/GTK/mobile side of things, where client side decorations are considered the way to go and the standardization comes from assuming everyone will be using the same set of UI libraries.
It seems to fit that specific use pretty well, and there's a lot of things I like, but it's certainly got some catching up to do when it comes to the mix-and-match flexibility of the X-server/compositor/window manager/client stack.
I am not sure if Wayland actually intends to catch up. Mostly the work seems to focused on supporting Gnome and KDE without bothering with all the rest. For example, there was a discussion a while ago about taking screenshots. Adding a protocol extension for that was declined for security reasons. Instead, the compositor itself should contain that feature. This only makes sense in the "big" desktop environments that contain everything from the compositor to the utilities and the kitchen sink.
That's just Gnome's opinion. wlroots and KDE are working together to standardize these sorts of protocols, just in the past few months our screenshot and screen capture protocols began to stablize.
How does that work securely? What determines if a process can take a screenshot or not? I mean clearly (I hope) only the compositor has access to all the pixels and needs to capture the image, but what determines who can request it to do so?
>What determines if a process can take a screenshot or not
We're slowly working on standardizing means of granting third-party software access to these protocols, but a cross-compositor mechanism has not yet been built. It is entirely possible for the compositor to only allow certain clients to use certain protocols, though. A mechanism like Android's "grant app this permission" popup, for example, might be possible. Today sway lets you configure different executables to receive different policies.
> A mechanism like Android's "grant app this permission" popup, for example, might be possible.
What possible relationship could this sentence have to the question of determining "if a process can take a screenshot or not?"
The correct answer for an ostensible improvement on X is that arbitrary processes should not be able to take screenshots, ever. If you start punting that question to the app users we're back in the land of Certificate-Error-Continue-Not-Recommended.
Even on this Chromebook I'm using, I'd shut it down immediately if Chrome legitimately popped up a request from a site asking for the permission to take screenshots.
Besides, most of the time on Gnu/Linux it's the buggiest processes for which I want screenshots to send to the developers. If no one in the Wayland community has a design that fits that use case please just leave screenshot functionality out altogether.
Well, with the way we hope to do it we'll leave it to your package manager to establish trust in most cases. So if you install a screenshot tool from your package manager, it'll be installed with all of the necessary permissions set up, and you'll never be prompted. It's important to us that users are able to use tools and workflows that they're comfortable with on X in a secure manner on Wayland.
>> It's important to us that users are able to use tools and workflows that they're comfortable with on X in a secure manner on Wayland.
X is a free-for-all. X-eyes is cute but should not be possible.
At some point, a web application is going to want to take a screen-shot (webX anyone?). The web browser will then be given permission to take screen shots without user interaction, and then it's all over. Sharing ones screen is NOT a browser function, it's an OS function. Changing the way software developers see this is the correct path forward, but it's hard. Providing people the same functionality that X did will lead to the same problems that X has.
- the client and compositor need both implement this protocol extension
- the client needs to ask the compositor whether it should provide its window decorations
- the compositor needs to cooperate and tell the client that the decorations are server-side
Is that right?
I'm also puzzled by something else now: in Wayland, any access to absolute screen coordinates is considered a security risk. So how can a client provide windows decorations then? The main functionality there is moving the window around, which means setting a new absolute window position after a user interaction. How is this possible when the position is hidden away?
EDIT: if I had read the compositor source code before posing the question, I'd have known that the client merely provides the window decoration as a visual area, but not its behaviour. The move and resize behaviour itself including user interaction is part of the compositor.