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

[Bill Spitzak]

Jason Ekstrand wrote:

> Here is the problem.  Say you have two pointers P and Q and two and two 
> windows A and B.  P clicks on A and A a is now active.  Q clicks on B 
> and now B is active.  Then P goes and clicks on B.  However, B is 
> already active so it doesn't request an activation and A stays active 
> with pointer P.  This assumes we are trusting clients to request 
> activation.  The other option is that we simply force a 
> click-always-activates model and clients are constantly fighting the 
> compositor just to make modal dialogues work.

Clients have to activate themselves on all clicks whether or not they 
know they are active. Otherwise it is possible that another client has 
grabbed the activation. The client will not see the deactivate until 
after the click and has no reason to know it is incorrect, and the 
compositor may think the client purposely did not activate itself and 
thus cannot fake it either.

Or I guess a client could activate itself on deactivate events and rely 
on the compositor ignoring them if it really should not be active but 
that sounds more like a kludge.

This has nothing to do with modal dialogs. The client knows what surface 
is modal and can send that (rather than the surface the cursor in on) 
with the activate request.

> That's not correct.  Timestamps are seat specific but timestamps are not 
> the same as serials.  Timestamps are local to the seat.  Serials are 
> actually compositor-global in weston and, in order to make things work, 
> should probably at least be client-global in other compositors.

Oh that's good news. Okay ignore my previous response about this, sounds 
good!