Who is working on the non-drawing parts?

[Kristian Høgsberg]

On Thu, Nov 25, 2010 at 9:43 PM, Gerry JJ <trick at icculus.org> wrote:
> Den Wed, 24 Nov 2010 13:01:06 -0500
> skrev Marty Jack <martyj19 at comcast.net>:
>> Also, I don't yet fully buy
>> into the part about no client controlled window placement.  We need
>> some way for docks to position themselves appropriately.
>
> Client controlled window placement is important.  Without it, you
> can't restore multi-window sessions properly (or even single-window, if
> position matters), splash screens won't be centered as they should be,
> dialog boxes will pop up at random positions, and whatever else that
> wants to put specific windows at specific positions on the screen for
> other (possibly good) reasons won't work.  Some things may have less
> valid reasons, but that's a tiny issue compared to not being able to do
> all those things properly under Wayland.

All of those can be handled by the compositor.  The key is to let the
compositor know what kind of window you're showing and how it relates
to your other windows.  Once the compositor knows whether you're
showing a new toplevel window, a dialog box for an existing window or
a popup menu, the compositor/wm is always in a better position than
the client to determine where that window should be.  The core of the
issue is that the compositor may at any time be applying
transformations to the clients windows that it can't express to the
client.  If a client computes the exact location of a dialog box or
popup menu, there is an implicit assumption that the client knows it
current location and can compute from that a good location for the new
window.  That's just not the case in a composited environment and it's
one of the assumption that makes it impossible to really fix input
redirection.

(Disclaimer: session management isn't even at the hand-waving stage
yet, but I'm pretty sure we can deal with that without requiring
clients to specific their position on screen).

Kristian