[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
spitzak at gmail.com
Mon Nov 4 23:12:03 CET 2013
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
More information about the wayland-devel