Michal Suchanek wrote:
I guess there is one thing that can be done. The compositor could publish a hint to the application that it takes care of decorating the windows (even if it is a tiling WM and in fact does not but the user does not want any decorations in the first place)
Indeed this looks like a good idea. In fact doing some sketches it appears to be necessary for the compositor to tell the client to delete the decorations on each edge independently.
and the client could publish a hint that it does draw decorations and its windows should not be decorated by the compositor (or it does not want decorations because it is a clock window and decorating it makes no sense).
I don't think the compositor should ever decorate the windows so I very much disagree with any idea like this.
It cannot draw into the texture for the window, as that memory belongs to the client. If the client is doing internal double-buffering, the compositor does not even have a pointer to the texture!
Therefore the compositor would have to add extra surfaces that are the decorations. This could either be a larger underlay window, an overlay with a big transparent hole, or thin windows placed around the edges. The problem here is that resizing the window needs to be an atomic operation so the user never sees a partial update. This means that both windows must resize and have their image replaced in the same operation, while the images are produced by two different processes! This sounds very complex and difficult.
When you add to this the insane amount of little details that clients need to send to control the decorations (such as whether there should be a resize box, etc) I think it is nonsense to ever consider such things.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
