Wayland Window Management Proposal
spitzak at gmail.com
Tue May 10 18:27:32 PDT 2011
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
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.
More information about the wayland-devel