Who is working on the non-drawing parts?

[Fred Morcos]

2010/11/29 Kristian Høgsberg <krh at bitplanet.net>:
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

I second Kristian's opinion. Panels can request certain placements in
sequence of their priorities (left, right, top-left, ...) and the
compositor will be the best to decide which area is free
(non-overlapping with any other panels already running) to contain
that panel. I find that quite nice but also limiting.

I wonder, isn't that problem analogous to the client-side decorations?
Allowing client-side decorations but rejecting client-side placement
seems hypocritical to me.

I really think the X way (server, wm and clients) is the best way and
truly is one-size-fits-all. A humble idea that I thought of was to
have:
wayland <-> [compositor <-> decorator] <-> clients (where <-> denotes
talks-to)... But that looks awfully familiar...

Regards,
Fred Morcos