[Question] Z-order management in Wayland

[Carsten Haitzler (The Rasterman)]

On Thu, 31 Jul 2014 15:44:40 -0700 Bill Spitzak <spitzak at gmail.com> said:

> On 07/31/2014 03:21 PM, Carsten Haitzler (The Rasterman) wrote:
> 
> >> Wait a second, how is click-to-raise being done?
> >
> > not by the client - by the compositor. the client has no control over that.
> 
> That does not work. The client has to be able to decide whether a mouse 
> click will raise the window.

no it doesn't. it doesn't work like that in x11 and things work just fine. i've
been doing wm's and toolkits for a long time. wayland is well designed, if
perhaps a little spartan. :)

> The most obvious thing that does not work is drag & drop.

what has that got to do with a click raising or not? dnd is a separate protocol
element with its own semantics.

> It makes it impossible for a click to both raise the window and create a 
> floating window without blinking.

not so. :) as dnd is triggered on a DRAG = the mouse has MOVED beyond a
certain threshold beyond the place that the click happened - the creation of a
dnd icon is long after the click and the raise. this is precisely how it works
in x11 today - the click is intercepted by the wm with a passive grab and an
allow events to hand it on. that click may cause the wm to raise the window.
even the override-redirect window the client makes for dnd is fine...

in wayland dnd is a special thing and the compositor is directly involved

> And unless something MUCH more complicated than the current parent in 
> xdg_shell is used, it makes multiple-window software impossible. At 
> least a full Directed Acyclic Graph of multiple parents for every 
> surface is needed, though I really suspect an entire interpreted 
> language is needed to describe window stacking.
> 
> This has to be fixed or you are violating the "every frame is perfect" 
> design criteria for Wayland.

nope. when a drag starts an icon surface (to be dragged about) it given to the
compositor. the compositor can happily ensure that that surface is at the
correct x/y AND always above everything - like the mouse pointer. lok at the
start_drag protocol request. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com