xdg shell status and gaps
spitzak at gmail.com
Thu Sep 25 13:18:24 PDT 2014
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
> 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.
More information about the wayland-devel