[PATCH v2 1/2] shell & compositor: add parameters for set_fullsceen

[Bill Spitzak]

Pekka Paalanen wrote:

>>>> +#define WESTON_SURFACE_FULLSCREEN_NONE 0
>>>> +#define WESTON_SURFACE_FULLSCREEN_SCALE 1
>>>> +#define WESTON_SURFACE_FULLSCREEN_FORCE 2
>>>> +#define WESTON_SURFACE_FULLSCREEN_FILL 3
>>>> +#define WESTON_SURFACE_TYPE_CURSOR 0
>>>> +#define WESTON_SURFACE_TYPE_PANEL 1
>>>> +#define WESTON_SURFACE_TYPE_GENERAL 2
>>> Why is PANEL here? Panel as a concept should not exist here, it is a
>>> shell thing.
>> We need some type to figure out that is not the general one. For current
>> usage, it is panel.
> 
> Well, if we follow the current design, where all surfaces are in a
> single list, the fullscreen surfaces should be on top of the panels,
> and you don't need to special-case the panels. But it is very difficult
> to maintain the proper order in the surface list.

Setting fullscreen MUST NOT CHANGE THE WINDOW ORDER. Please!

I asked about this before and was told "oh no it won't change the order" 
but comments like this show that is obviously false. It sounds like you 
think that setting fullscreen on/off should raise/lower around the panel.

The client MUST be in control of window stacking. Otherwise floating 
control panels are impossible, in that the desired stacking from the 
client (an arbitrary and mutable directed acyclic graph) must be 
communicated to the compositor and updated synchronously with actions 
that change window order.

Current systems tried to restrict the graph to a single "atop" 
connnection per window (the "transient for" hint on X, the "parent" on 
Windows) and that the graph is immutable. Recently in X there have been 
attempts to fix the deficiencies by adding "window groups", hints to 
force window "layers", and some other cruft. None of these allow an 
arbitrary DAG and all of them are very complex and few window managers 
get them right.

It is hundreds of times simpler for the client to request window 
reodering. It can use it's own internal logic to choose which control 
panels to raise/map first, then raise the window to be below them. 
Please don't screw this up in Wayland. This also means that clients can 
choose to *NOT* raise on click, which would make overlapping windows a 
million times more user friendly and useful.

Proper handling of overlapping windows may very well be the killer 
feature of Wayland, don't blow it.