[PATCH v2 1/2] shell & compositor: add parameters for set_fullsceen
spitzak at gmail.com
Wed Jan 11 12:05:09 PST 2012
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.
More information about the wayland-devel