minimized and stick windows

[Rafael Antognolli]

On Wed, Jun 12, 2013 at 5:23 AM,  <sardemff7+wayland at sardemff7.net> wrote:
> 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.

If I'm not wrong, in the previous discussion we also discussed about
the possibility of leaving fullscreen as a shell surface type itself.
Though I don't have strong opinion about this, just trying to leave
another possibility open.

--
Rafael Antognolli