xdg shell status and gaps

[Bill Spitzak]

On 09/25/2014 07:32 AM, Jasper St. Pierre wrote:

>     1) Marking dialogs as modal (needed so we can implement the 'attached
>     modal' visuals of gnome-shell

I notice this one was ignored. There seems to be some set of people 
working on wayland that hate overlapping windows and want to guarantee 
they are useless.

Anyway, I have only posted about this about a billion times but will try 
again, though it seems a hopeless task:

1. All windows have a "parent" window. If not null the compositor keeps 
the child atop the parent and syncs up map/unmap. This may seem really 
simple, but wait:

2. Clients can change the parent of any window at any time. This has no 
visible effect until one of the windows is raised or mapped or unmapped. 
This is to allow more complex hierarchy than a tree without making the 
api fiendishly complex (gimp's overlapping dialogs will work perfectly).

3. Raise NEVER happens unless the client requests it. This is so the 
client can change the parenting and create/destroy child windows before 
the raise. This is VITAL for Wayland's "every frame is perfect" 
guarantee and cannot be waved away like some people here seem to think. 
It is also necessary so that drag & drop from a lower window works as 
Windows users expect. And yes, boo hoo, it means a client can ignore 
click-to-raise. That's a FEATURE.

4. To support what you are probably calling "modal", the client can take 
keystrokes it gets for any window and pretend they went to the modal 
dialog. Do not require the user to click or move the pointer to the 
modal dialog, that is incredibly stupid! So that panels can highlight 
the window that is actually responding it may be useful for the client 
to send a request moving the keyboard focus to it.

>     2) Lowering windows (used e.g. by GtkInspector to get out of the way
>     when picking a window
>
> I'm not comfortable adding this. You can hide briefly the inspector by
> giving it a 1x1 blank surface and emptying the input region. Perhaps we
> should make this equivalent to what the "NULL surface" semantics are.

I agree it would be better to just hide the window. Pointer lock (being 
discussed elsewhere) should not be lost when this happens. It sounds 
like the loss of grabs is why you lower rather than hide in X. Also if 
your client wants to identify the clicked window it will need some 
privileges.

>     3) Raising or activating windows (needed e.g when activating a
>     pre-existing window of a single-window application)

This has been discussed though for some reason they are calling it 
"attention requested". I would instead call it "raise" and make it the 
same as the above raise request that is needed to make overlapping 
windows work. The request includes the event that triggered it, and the 
compositor is aware of what windows are mapped and how they overlap and 
where the mouse and keyboard focus is, so it can easily figure out 
whether to do an actual raise or flash an icon or whatever.

>     5) Finding out if there is desktop chrome that should be avoided (ie.
>     'workarea') ? (Useful e.g. for window size heuristics)
>
> This will be handled by the probe extension, but I'm not really sure why
> you need this. You can't manually place your window with global
> coordinates. "Avoiding" anything doesn't make too much sense to me.

I think he wants to know the maximum size a window can be, even though 
he can't place it. Not clear if just requesting the window initially 
maximized is enough. Need more info on exactly what he is trying to do. 
One possibility is he only wants to maximize in one direction.

>     6) Snap-back animation if a drag ends unsuccessfully
>
> This should be handled by the compositor, not by the app. It can keep
> this surface alive and do the animation itself.

What? I'm pretty certain the client has to do this. Only the client 
knows where the position to snap-back to is. And...

>     7) Root window drop
>
> When is this useful?

As he pointed out he is really interested in why a drop failed. He wants 
to do something other than snap-back, which is another reason the client 
has to do snap-back animation, since it may not want it.