Created attachment 191975 [details] [review]
stack: tweak layer names a bit and add a new layer

Rename META_LAYER_TOP to META_LAYER_ABOVE, and META_LAYER_BOTTOM to
META_LAYER_BELOW, both to match the EWMH hints, and because they are
not the top and bottom layers.

Rename the (unused) META_LAYER_FOCUSED_WINDOW to META_LAYER_TOP. This
comes between FULLSCREEN and OVERRIDE_REDIRECT, and can be used for
the shell's visible-in-fullscreen chrome layer. Put windows in this
layer if they are both META_WINDOW_DOCK and wm_state_above.

Remove the hole in layer numbering left by an old bugfix.

Created attachment 191976 [details] [review]
window: don't deny focus due to overlap with shaped window

Mutter will deny focus to a new window if there is a wm_state_above
window that will block it from view. Ignore shaped windows in this
comparison, since the bounds of the window don't actually tell us
whether the windows will overlap in that case.

Review of attachment 191976 [details] [review]:

Make sense to me.

Review of attachment 191975 [details] [review]:

Looks mostly good, but "put[ting] windows in this layer if they are both META_WINDOW_DOCK and wm_state_above" needs some clarification on on the rationale.

::: src/core/stack.c
@@ +253,3 @@
+        layer = META_LAYER_BELOW;
+      else if (window->wm_state_above)
+        layer = META_LAYER_TOP;

I don't quite understand that change - is it to make sure that wm_state_above works for overlapping DOCK windows? And more importantly, why place them above fullscreen windows?

(In reply to comment #4)
> needs some clarification on on the rationale.

> why place them above fullscreen windows?

"Because that's the behavior I needed". This is for chrome with the visibleInFullscreen flag set (eg, the onscreen keyboard). If it's going to be visible when you have a fullscreen window, then it needs to be above META_LAYER_FULLSCREEN (but still below META_LAYER_OVERRIDE_REDIRECT).

Actually... maybe we could make it override-redirect, and just rely on the fact that newly-created popup menus, etc, would be mapped above it, not below it...

(In reply to comment #5)
> "Because that's the behavior I needed". This is for chrome with the
> visibleInFullscreen flag set (eg, the onscreen keyboard). If it's going to be
> visible when you have a fullscreen window, then it needs to be above
> META_LAYER_FULLSCREEN (but still below META_LAYER_OVERRIDE_REDIRECT).

I see, I wasn't aware that you were planning to use _NET_WM_TYPE_DOCK for the shell chrome (though thinking about it it makes sense).


> Actually... maybe we could make it override-redirect, and just rely on the fact
> that newly-created popup menus, etc, would be mapped above it, not below it...

Mmmh, I guess that would work, but your current approach looks cleaner. It is at the very least a stretch of EWMH though[0] (e.g. not following a "recommendation"). On the other hand, given that the recommended layering de facto implies _NET_WM_STATE_ABOVE for _NET_WM_TYPE_DOCK, I wouldn't expect much (any?) use in practice, so I tend to favor the current approach.

Still, I'd like
 1. a confirmation from Owen that he's OK with that interpretation
 2. a mention of the intended use in gnome-shell in the commit message


[0] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER

(In reply to comment #5)
> (In reply to comment #4)
> > needs some clarification on on the rationale.
> 
> > why place them above fullscreen windows?
> 
> "Because that's the behavior I needed". This is for chrome with the
> visibleInFullscreen flag set (eg, the onscreen keyboard). If it's going to be
> visible when you have a fullscreen window, then it needs to be above
> META_LAYER_FULLSCREEN (but still below META_LAYER_OVERRIDE_REDIRECT).

Note that override-redirect windows don't stack in META_LAYER_OVERRIDE_REDIRECT (any more) they just stack whereever they are stacked. I think that layer constant is actually pointless.

(In reply to comment #6)
> (In reply to comment #5)
> > "Because that's the behavior I needed". This is for chrome with the
> > visibleInFullscreen flag set (eg, the onscreen keyboard). If it's going to be
> > visible when you have a fullscreen window, then it needs to be above
> > META_LAYER_FULLSCREEN (but still below META_LAYER_OVERRIDE_REDIRECT).
> 
> I see, I wasn't aware that you were planning to use _NET_WM_TYPE_DOCK for the
> shell chrome (though thinking about it it makes sense).
> 
> 
> > Actually... maybe we could make it override-redirect, and just rely on the fact
> > that newly-created popup menus, etc, would be mapped above it, not below it...
> 
> Mmmh, I guess that would work, but your current approach looks cleaner. It is
> at the very least a stretch of EWMH though[0] (e.g. not following a
> "recommendation"). On the other hand, given that the recommended layering de
> facto implies _NET_WM_STATE_ABOVE for _NET_WM_TYPE_DOCK, I wouldn't expect much
> (any?) use in practice, so I tend to favor the current approach.
> 
> Still, I'd like
>  1. a confirmation from Owen that he's OK with that interpretation

I've delegated having an opinion here :-) ... however my quick reaction is that "Put windows in this layer if they are both META_WINDOW_DOCK and wm_state_above." is a little hacky. If neither dock nor above implies above fullscreen, how does the combination end up that way? And are we sure that some real docks aren't set above?

It seems to me that if we're going to be going around creating windows for our own internal purposes, it would be better to have some API to create a MetaWindow and X window rather than to be creating X windows and then asynchronously having the X server tell us about them and creating the MetaWindow only when they were mapped. And if we had a MetaWindow, then we could add API to make it behave like we wanted.

(Note that such a window would have to be always mapped, since we have no ability to represent a withdrawn MetaWindow, but that shouldn't be a limitation here.)

So I eventually decided that the right fix here was probably to have a separate (shaped) window for each chrome item, rather than a single full-screen chrome window, which should remove the need for the "don't deny focus due to overlap with shaped window" patch. And as Owen suggests, they should be created by some mutter API, which should return a MetaWindow directly. (Though it might be simpler to have it be an async API, so you can just let the MetaWindow be created by the usual channels? That might complicate the shell side though.)

The "add a new layer" part of the first patch may still be useful for getting the chrome windows to stack in the right place. Otherwise there will need to be some sort of interaction with the window stack code.

Bug 633620 has been fixed using a different approach, so I'll tentatively close this as obsolete. Feel free to reopen if you still consider this useful elsewhere.