minimized and stick windows

[sardemff7+wayland at sardemff7.net]

On 12/06/2013 09:57, Pekka Paalanen wrote:
> To get the big picture, let me reiterate the surface classification as
> a whole, the way I see it.
>
> Surface roles, exclusive:
> - cursor
> - drag icon
> - shell surface

Each role is an interface then? Simple and efficient, I love it.


> Shell surface types, exclusive:
> - top-level
> - transient (umm, what was this for, again?)
> - popup (menu?)

Transcient is for dialog (modal?) boxes, isn’t it?
Each type is a one-shot request on a new created surface. Again, simple 
and efficient, love it too.
It may be a bit more clear, see below.

> Top-level shell surface states, each more or less toggleable on its own:
> - maximized
> - fullscreen
> - minimized
> - sticky
> - always-on-top or some equivalent layer thing
> ...

> Does this make sense?

Yes.


> That is, only a top-level surface, which we should probably be calling
> as an application window, can be maximized etc., and I think the
> discussion was that it can be many things at once, like maximized and
> minimized.

Right, it is useful and not that hard to implement.


> I don't think the states make sense as types, I would prefer the above
> hierarchy. A shell surface can only have one type at a time, but the
> states are not that restricted. It gives a nice tree-like hierarchy,
> instead of a directed graph where several surface types can have the
> same states. The tiling-WM developers would be concerned only about the
> top-level shell surface states, and could hopefully support all the
> shell surface types, which should make the difference between floating
> and tiling WMs more manageable.

I agree.


> Protocol-wise, this means that requests set_maximized and
> set_fullscreen would be deprecated as is, and replaced with the state
> setting request. Request set_toplevel would deprecate the part of its
> behaviour where it changes a surface into normal state.
>
> We cannot remove the deprecated functionality, I believe, so it must be
> kept working, and just plumbed into the new kind of internal state
> change machinery inside weston.
>
> However, it's not that simple. Some states need parameters. Maximized
> needs an output, and fullscreen a few things more. Always-on-top
> equivalent might want a layer number or something. Therefore I'm not
> sure a single set_state request will work.

At protocol level, we may be better using new interfaces.

wl_shell will gain three requests:
— get_toplevel_surface(class, title): returns a new 
wl_shell_toplevel_surface
— get_transcient_surface(wl_shell_toplevel_surface): returns a 
transcient one
— get_popup(wl_shell_toplevel_surface): returns a popup surface

That would duplicate some requests between the three interfaces (or 
maybe two, if transcient and popup can share one).
Backward-compatibility would be both easier and harder than keeping 
wl_shell_surface around, as we have to maintain a compatibility struct 
in the compositor, but that would be a simple struct { type; union { 
toplevel; transcient; popup; }; }.

That would allow to extend the configure event in a nice fashion, that 
tiling WM will love (e.g. for decorations).

> Anyway, that's just what came to my mind now. I don't recall any of the
> earlier discussions anymore, maybe there were solutions to some of
> these issues, maybe not.
>
> Did we ever discuss the possiblity of fullscreen being a special kind
> of maximized, btw? If you look at the state list above, everything is
> orthogonal (toggleable independently) except maximized vs. fullscreen.
> This is just as a concept, how it maps into protocol is a different
> matter.

Fullscreen, especially for games, is a completely different thing (e.g. 
modesetting). We can have two cases here: “basic” fullscreen, which is 
just maximize with panel removed (and the app will use the normal 
decoration mechanism here, no fullscreen state), and plain fullscreen, 
which would be another surface type.
I *think* most apps (games) already have heavy switching, so destroying 
and creating a new surface should not be a problem here, imo.


Cheers,

-- 

Quentin “Sardem FF7” Glidic