Emilio Pozuelo Monfort wrote:
Hi Bill,
On 30/01/14 23:33, Bill Spitzak wrote:
There really should not be a "fullscreen layer" which is what is causing this
problem. "layers" are imho a mistake except for the desttop and the mouse
cursor.
What I think needs to happen:
Fullscreen, normal windows, and "panels" can be arranged in any stacking order,
except the compositor enforces this rule:
The "panels" are always just below the lowest fullscreen window. If there are no
fullscreen windows then the panel is above all windows.
There are several ways to enforce this but one that matches current window apis
is:
1. When a window is "raised" and there are no fullscreen windows, the panels are
also raised to remain above it. If there are fullscreen windows then the panel
is not moved. Note that a window can be raised above a fullscreen window, thus
solving this bug.
2. Whan a window switches to fullscreen it is also raised (thus it will end up
above the panel). (an alternative is to lower the panel but that is not standard
behavior in existing windowing systems).
3. When the last fullscreen window switches to non-fullscreen, the panel is
raised above all windows.
I think this could work well. It would indeed solve
https://bugs.freedesktop.org/show_bug.cgi?id=74219. I just disagree with one
detail: the panel should always be on top except when the top surface is
fullscreened. So if there are two surfaces, a normal surface above and a
fullscreen surface behind it, then the panel should be raised (that would be
consistent with what we currently do and with what gnome-shell does).
Thanks. I think you are correct that a rule of putting the panel above
the highest non-fullscreen surface would work and be just as consistent
as my suggestion of putting the panel below the lowest fullscreen surface).
The only argument I have for my version is that if the fullscreen
surface has child surfaces (such as popup dialogs) then these should not
raise the panel. This then requires the compositor to distinguish these
surfaces from other non-fullscreen ones. However it seems likely that
the shell api is going to have this information (in the form of a parent
surface indicator on each surface).
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
