[PATCH weston] Fullscreen surfaces

[Bill Spitzak]

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).