4 ms·

Yeah, we feel the same way. We've recently standardized a protocol[0] for negotiating server side decorations and client support is underway for Qt and GTK+. [

• gmueckl 8y ago
  For that to work, - 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.
  • eadmund 8y ago
    > 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).
    • Sir_Cmpwn 8y ago
      No, it's definitely poorly thought out. This is one of the problems that we're trying to deal with over in the wlroots camp.
    • Crespyl 8y ago
      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.
      • gmueckl 8y ago
        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.
        • Sir_Cmpwn 8y ago
          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.
          • phkahler 8y ago
            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?