[PATCH] shell: Implement wl_shell_surface_set_notification

[Gregory Merchan]

On Sat, Dec 29, 2012 at 7:55 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> Oh sh.. it is a "layer".
>
>> +     struct weston_layer notification_layer;
>
> This is not good. Please figure out a way so that clients can control the
> window stacking without having to copy every idea that a client needs into
> the compositor.
>
> Recommendation:
>
> Each surface has a "parent", if it is not null, the compositor keeps that
> surface above the parent, by moving it upward if the parent is moved so the
> order is always enforced. It never causes a surface to move downward.
>
> The client is allowed to change the "parent" at any time. This will cause an
> upward movement of the reparented surface if the new parent is not null and
> is higher than the surface.
>
> Reparents are deferred until a commit on both the old and new parent.
>
> The compositor NEVER raises a window except by a raise command from a
> client. This is so the client can create/destroy/reparent any other surfaces
> it wants before raising one.

This is also important for getting drag-and-drop working correctly. I
tried the weston dnd demo recently and was saddened to see it does not
work correctly (i.e. according to the expectations of most computer
users): the ButtonDown immediately set focus and raised the window
rather than allowing a drag without focus or stacking change. I tried
modifying the demo, but I couldn't find any way to reject focus or
avoid the window being raised. (Sorry. I don't know the new names for
these things I know on X.)

The exceptions to client stacking are, IMO, just the layers seen in
the patch. They are system features which just happen to be
implemented by some special clients, and one special mode,
full-screen. Most user expectations can be met on X in the absence of
a window manager, though in practice no one has ever done so. The
expectations that cannot be met are keyboard-based focus changes
between clients, and windows permanently above (panel, fullscreen) or
permanently below (background) all other clients. (Ignoring modern
compositing expectations, of course.)

> In reality the "parent" stuff is not needed at all, there could just be a
> command of "put surface a above surface b" that is deferred until a commit
> is done on b. The parent stuff does allow the most common hierarchy to be
> communicated to the server, while as long as the parent can be changed it
> allows any arrangement a client wants. The parent hierarchy also allows the
> connections between surfaces to be known to panel applications.
> . . .

That reminds me: is there anything like icon windows in any of the
compositors that have been written? I couldn't find that in weston.