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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
