minimized and stick windows

[Pekka Paalanen]

On Tue, 11 Jun 2013 16:31:59 -0300
Rafael Antognolli <antognolli at gmail.com> wrote:

> Starting code here. Following are some comments.
> 
> https://github.com/antognolli/wayland/commits/minimize
> https://github.com/antognolli/weston/commits/minimize
> 
> I didn't add code for the events that ask state changes from the
> compositor, neither any code related to minimize yet. I tried to first
> change the current maximized surface type to be just another state, as
> suggested at some point in this thread.
> 
> So, it ended up very hackish IMHO. In order to do that, when the
> surface type is set to maximized, I change it to set the maximized
> state instead, which is currently working correctly (from my tests).
> But when the surface type is set to anything else than maximized, I
> have to unset the maximized state, to keep the same behavior as before
> these changes.
> 
> I need to know if I should follow this path, in which case I'll
> improve the above code (some refactory can take place), or if we
> should use another approach. Maybe the minimized state should be in
> fact another surface type, and we would only have states for things
> like always_on_top and sticky (and any other that may come next). Or
> maybe we can keep the same surface types that we had already, and just
> add minimized as a state.
> 
> What are your opinions about this?

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

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

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?

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.

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.

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.

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.


Thanks,
pq