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

[Pekka Paalanen]

On Wed, 20 Mar 2013 22:06:22 -0600
Scott Moreau <oreaus at gmail.com> wrote:

> Hi Jason,
> 
> On Wed, Mar 20, 2013 at 7:56 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> >
> > There is one more question that I think needs to be answered.  And
> > that is: do we handle things in terms of set/unset or in terms of
> > set_maximized, set_fullscreen, set_minimized, and set_normal (probably
> > want a better name for that one).  Really, which of those two we do
> > doesn't matter that much because the toolkit can force it either way.
> > It's mostly a matter of who tracks the state and handles it.  I think
> > I like simply setting the state instead of keeping track of set/unset
> > better, but I'm open to discussion on that.
> 
> I have this all working in gh next. The only thing left to consider
> that I can think of is: Do we want to support 'unmaximizing or
> unminimizing (or unfullscreening) a surface retains stacking state'.
> So basically if there is a bottom-level surface and you state change
> it then toggle it back, do we always want it on top no matter what? Or
> do we want to optionally support retaining stacking order on state
> restore (setting back to 'normal'). If we want to support this
> feature, then a new un* request is required for each state set
> request. I move that we do support this feature and I'm working on
> this in gh next.

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?

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?

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?


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?

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.

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?


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?

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?

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

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.


Thanks,
pq