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

Hmm... I'm still trying to understand this part, but are these calls
used to create the shell surfaces?

I also don't get exactly what would be the approach for passing
parameters to the "state set" calls. Would we have a custom data field
on the state_set call, or have specialized state set functions, each
with its own set of parameters, like state_maximized_set,
state_minimized_set, etc?

I'll try to summarize things here:
https://github.com/antognolli/wayland/wiki/Surface-States

Feel free to edit it if you want, I think that it's open to anyone to edit.

Regards,
--
Rafael Antognolli