Kristian Høgsberg wrote:
I had a quick read through this and there is a lot of overlap with how Wayland works today... are you proposing to change how Wayland works or are you not familiar with what's already in place?
A lot of this is based on my understanding of how Wayland works, and from the XML description of the protocol. I tried to document what I believe but has never been really stated for Wayland.
Main addition I made without previous knowledge was the parent and the task objects (so that a task manager client can figure out what to display), and the window management events (rather than try to guess what happens based on movements of the windows, which seemed to be what was planned for Wayland).
Anyway, for decorations and tiling window managers, bear in mind that CSD is not about insisting that clients always draws decorations, but about making clients draw the decorations *when* decorations are desired.
I mostly see CSD as meaning "the server never draws any kind of decorations". I agree it is a good idea for the server to be able to tell the client to not to draw decorations (done in this proposal with the resize events having 4 flags to turn the edges on/off and another flag for the title bar). But the server must *never* draw them, because that would require the api by which the client describes the decorations to the server, which is the source of the complexity and interface lock-in that we have in X and Windows.
I also believe window actions such as move, map, and raise must be client-side. Otherwise correct movement of child windows will require an equally-complex api to send this information to the server. So I really tried to make it clear how I see this working. Proper child windows where the app has complete control could be a major user interface advantage over Windows and OS/X.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
