[PATCH wayland v3] protocol: Add minimize/maximize protocol

[Scott Moreau]

Hi Pekka, thanks for your comments here.

>
> Scott,
>
> do you mean that these unminimize, unmaximize, etc. requests would
> actually work like undo? Unmaximize would undo what the last
> maximization did, as opposed to just set_normal which might do
> something slightly different since its aim is to make the window
> normal, not undo something?

Right, I am asking if there is a case for such functionality. The more
I think about it, it seems like it might seem like a bug in normal
desktop usage. But if you happen to have another external program that
you might want to use to manipulate window states, maybe you'd want a
finer grain control there. I'm not sure of all the possible cases,
which is why I'm asking for input.

>
> If so, does it make sense to have state specific undo requests?
>
> Consider this sequence, driven by the client:
> 1. the window is normal
> 2. maximize the window
> 3. minimize the window
> 4. unmaximize the window
>
> What happens at step 4? Is it possible to define the outcome of
> such cases in an intuitive way?

This illustrates the point perfectly. This is definitely all about
semantics and expected behavior. This must be clearly documented in
the protocol description. I had it working so you could do this. You
could minimize, toggle maximized state and unmaximize with the correct
state. This works fine when doing
maximize->minimize->unmaximize->unminimize but causes a frame glitch
when doing unmaximize->minimize->maximize->unminimize. The frame
glitch is probably easily worked around. However, it is noteworthy
that if you have this behavior, then you can't assume that maximize
and toplevel will be counterparts, but instead, that you'd need
explicit unmaximize notification.

>
> Does it ever make sense to send a unBAR when the previous operation
> was FOO, not BAR? Could you do with just one undo request for all
> the un* cases? (If not, why?)
>
> What if a client undoes twice? N times?
>
> Add this to the above sequence:
> 5. unminimize the window
>
> Is the window now in normal state or maximized state?

Since this email, I have made it so you cannot toggle maximize while
in a minimized state. This is the way xfce works and it's reasonably
sane behavior.

>
>
> I'm thinking this purely from the compositor point of view, and I
> don't have any tangible suggestions here, but the above just
> seems to generate more illegal than legal sequences, which also
> means the code in the compositor must be checking for all the
> illegal cases, and emit errors. The illegal sequences might not
> make any sense to use, but the compositor (and the protocol spec)
> must be aware of what happens when they are received. It might be
> worth to actually draw (as on paper) the state machine with all the
> requests you might get in each state.
>
> Is there any way this protocol could be designed in a way, that
> illegal sequences would not exist, or at least would be in the
> minority?

I would like to dismiss the term 'illegal' here in it's entirety
because it is biased by definition. I prefer 'possibly problematic'.

>
> As such, having only the set-requests without corresponding
> un-requests would cut down the number of illegal (or just
> unintuitive) sequences a lot. Adding a single undo request won't make
> it much worse, the only suspicious case is undoing multiple times
> in a row, I think. Adding corresponding un-request for each state
> request leads to a minor combinatorial explosion of possible
> sequences for which there is no obvious idea on what should happen.

Yes, this is an orchestration between the clients and shell. It
doesn't sound too complicated until you take a look at what's actually
going on. I did not have time to draw a picture but mainly, you have
to keep everyone in sync. And by everyone I mean:

1) The shell plugin
2) The wl_shell_surface clients
3) The xwayland clients
4) The desktop-shell client

These all must be 'on board', for everything to go as intended.

>
> Btw. how do you intend to restore the stacking order on undo, in
> practice, in the Weston implementation? It is possible other
> windows have been deleted, created, and shuffled between set and
> undo, so what will you use as the anchor to go back to?

I am using gh next as a testbed to work out many of the details.

>
>
> As for the whole idea of undoing stacking order changes; you seem
> to assume that set_<state> requests will change the stacking order.
> Is that right?

The stacking order is (optionally) only changed when a state is restored.

>
> Or is that just a convenient workaround for the fact, that we do
> not have protocol for explicitly controlling stacking order? So you
> just add implicit stacking side-effects to unrelated requests?

There's a lot of missing protocol, again, gh next is the testbed for
the current implementation I have.

>
> If we had orthogonal requests for controlling stacking order, then
> set_<state> requests would not need to touch stacking order at all.
> Excluding stacking order, is there something else you would want to
> undo, or would the whole undo thing become unneeded?

I would like to think, that there are far and few between cases where
we'd want such a behavior. Weston is reportedly a toy, not a real DE
and I'm playing with it a bit. I'm not trying to enforce policy, I'm
trying to open up the possibility of doing more interesting things.

>
> I would like to strongly suggest to consider splitting the protocol
> into orthogonal concepts. That is what I did when I separated
> clipping and scaling from the sub-surfaces protocol. It may seem
> like more work to start with, but the end result will be cleaner,
> more intuitive, and more versatile. It will also allow you to
> reduce the interactions and implications, making designing the
> protocol easier, and leading to a better end result. The short-term
> downside is that you cannot take shortcuts in the design to have
> a certain use case running sooner; you will have all use cases
> running correctly later. As a compromise to allow development and
> testing, your implementation can violate your own spec while
> unreleased.

I'm not sure what you mean by 'splitting the protocol into orthogonal
concepts' here.

>
> Window state and stacking order often change hand-to-hand, but I
> see no reason to tie them together on the protocol level. That is
> why I would suggest to handle window state in one set of requests,
> and stacking order in a another disjoint set of requests. Moving a
> fullscreen window to the top could still be implemented by moving
> it to the fullscreen layer in Weston, but that really is just an
> implementation detail. From the client's point of view the
> fullscreen window is simply "on top" at that time.

The bottom line is, the four components I mentioned here, must work
together and be 'on the same page' regarding semantics. Each component
is responsible for it's own state tracking. I have found it is easier
to track state when the calls are in consistent pairs. This also
yields potentially more flexible control for the window manager (shell
plugin).

>
>
> Thanks,
> pq


- Scott