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

[Pekka Paalanen]

On Wed, 11 Jan 2012 12:05:09 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> 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!

Ok, I'll rephrase what I really meant, just forgot to write a tiny
subordinate clause in the above.

When a fullscreen surface is raised topmost, it should be raised on top
of panels. When some other surface is raised afterwards, the panels must
be raised too, if the other surface is not fullscreen.

Happy?

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

No.

Do realise, that the current implementation of the "window stack" does
not allow us to do things right. It needs to change, but currently it
is what it is.

We might not even need any "raise" operations for panels, we could just
skip rendering them, if there is a fullscreen surface the topmost of
"regular windows".

- pq