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). Regards, Emilio _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
