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!
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
