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