[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
spitzak at gmail.com
Tue Nov 5 19:36:29 CET 2013
Gregory Merchan wrote:
>> No the client must be in control and decide it does *not* want to be
> "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
- 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
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
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.
More information about the wayland-devel