[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.

[Bill Spitzak]

Gregory Merchan wrote:

> Viewport change as described by Bill:
> W to A: Request activation.
> A to W: Activate me and do these things, or don't activate me at all.
> W to Z: (1) You are deactivated; (2) Nothing.
> W to A: (1) You are activated (and by other events or by implication
> everything is done.); (2) You are not activated (and by implication
> those things are not done.)
> 
> If A was not activated, the compositor does the same with B, C, D, . .
> .. Z only receives the deactivation event when another client has
> accepted.
> 
> Do I describe what happens to Z correctly?

I think you described pretty much what I was considering, though I never 
even thought about it needing to reject the associated operations. But 
in any case...

> Viewport change as described by Greg:
> W to Z: You are deactivated.
> W to A: You are activated.
> A to W: Do these things.
> (By events or by convention everything is done.)

I am now convinced that what you want will work and is simpler.

I think I proposed sort of the same thing initially, but in my version 
the client was in charge of whether sloppy focus worked because I only 
said the compositor would ignore obviously-hostile clients. IMHO this 
was not a problem but others here certainly did not like it. I then made 
a big mistake by thinking this requied some kind of advisory activate 
event from the compositor.

In your scheme the client can try to activate on mouse enter but the 
compositor ignores it, achieving the same result of having the 
compositor in control of focus policy and avoiding the advisory activate 
event.

> I believe the compositor to client request must include a reason for
> the request if the client is allowed to completely refuse, so that it
> does not refuse in reasonable events like viewport changes. I think
> this makes things needlessly complicated.
> 
> On the other hand, if the client must make the request, it doesn't get
> complicated. The request and other changes can still happen
> atomically.
 >
> I suspect the cost of the freedom to reject activation is too high,
> but the cost of letting the client specify how to be activated is not
> too high. (Basically, what I said above.) This is just an impression;
> I haven't tried to lay it all out enough to even say it's my opinion,
> much less than to assert it is so.

I agree with all this analysis.

This is good. Lets see if anybody else is following this.