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

[Bill Spitzak]

Gregory Merchan wrote:

>> No the client must be in control and decide it does *not* want to be
>> activated.
> 
> "Sloppy focus, as a system-wide policy" refers to the list of 5
> policies which I gave in my first message in this thread. That is a
> policy which does not allow clients such control. (Did I mention that
> I think that and the rest of the first four policies suck?)

I *think* we are both describing the same thing (your "policy 5") but 
using different terms. Wayland should only have exactly one "policy" 
which I will try to describe, to see if we are talking about the same thing:

- The compositor can send a "activate request event" saying that it 
would like the client to activate.

- The client can send "activate request". This can be atomically 
combined with other changes to surfaces such as resizing, changing 
buffers, raising, and mapping/unmapping.

- The compositor can ignore the request, in which case it sends a 
"deactivate event" so the client knows it did not happen (note that I 
really want mis-matched activate/deactivate events or this is 
impossible!). Or

- The compositor can obey the request. If it receives requests 
out-of-order from multiple clients it is expected to do a reasonable job 
of replicating the result of them being in-order.

Things that are *not* allowed:

- The compositor cannot do any of these actions unless the client 
requests it (this is not physically enforced but clients assume it).

- The client cannot force anything to happen. It's request can always be 
ignored.

Now the question is how to get the "policies" that the user sees. I see 
three ways of doing this. To simplify lets assume only sloppy focus and 
click-to-type are wanted:

1. My proposal: Client knows which policy is in effect. If sloppy focus 
it sends an activate request on mouse enter. If click-to-type it sends 
it on mouse clicks. Compositor obeys these. The annoyance here is that 
clients may disagree about policy.

2. Jason's proposal: Compositor knows which policy is in effect. If 
sloppy focus it sends an activate request event on mouse enter, if 
click-to-type it sends it on mouse clicks. Client echoes these as 
activate requests and the compositor obeys these. The annoyance here is 
that non-trivial clients will need to figure out why it was sent the 
activate request event because it has to treat Alt-Tab differently than 
mouse-enter.

3. Your proposal: Client sends activate requests on *both* mouse-enter 
and mouse clicks. Compositor knows which policy is in effect, and 
ignores the incorrect activate requests. A problem I see is that to get 
glitch-free update the client will have to figure out if sloppy focus is 
on so it knows whether to draw surfaces activated when sending the 
request on mouse enter. However I feel this is not a huge bug and thus 
like this the best now.

Your description of #3:
>>> A compositor not using sloppy focus could indeed ignore
>>> signatures from crossing events, so it would be OK for clients to make
>>> the request in any environment, but if it is not necessary then I
>>> think it should not be done.