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

[Gregory Merchan]

On Tue, Nov 5, 2013 at 12:36 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> 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. . . .

No. I am describing the map. You are describing the path you want to take on it.


> . . . Wayland should only have exactly one "policy" . . .

That's not up to me. I don't think it's necessary to require a policy
for compositors. On the other hand, years of X have produced infinite
varieties of what is for most computer users the wrong thing, and not
one instance of "the right thing", so I do not think it would be
unwise to (at the very least) favor the 5th policy I gave.


> . . . 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.

That is not what I described, mostly because I kept the new things to
a minimum. It seems I hinted at but failed to explicitly mention what
serves much the same purpose: the activation event could provide the
signature for client activation requests. The hint was in my
description of the convention for valid timestamps [ 4) a window
manager message ]  on X11, but I failed to mention an analog when I
spoke of signatures in terms of Wayland events. This allows a client
with a compositor-activated surface to instead activate another
surface, but does not allow a refusal of activation except to make the
surface incapable of activation, for example by destroying it.

It is perhaps insufficient to have the compositor request that the
client make a request without providing a reason for the compositor's
request. The client would need to know if it being asked to activate
itself because of Alt+Tab-like switch, viewport changes, or any of the
other reasons a compositor might make the request of a client. This
probably means another enumeration needs to be defined, and how might
that enumeration grow?

Ultimately it falls upon the compositor to activate a surface. Without
some byzantine capabilities system hidden away from compositors, the
compositor must have the power to activate, even if as a matter of
convention it only does so after asking.


> - 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.

I don't know about "atomically combining", but I did describe an
activation request.


> - 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

I described a compositor ignoring requests with an invalid signature.
A "deactivate event" is not what I described; sending such an event is
negating, not ignoring. What I have described leaves the client
unaware that its request has been declined. The desktop issue of a
client seeking attention (and, so, a task bar blinking or something)
can be handled without the client receiving a denial; it would just
ask for attention in addition to or soon after asking for activation.


> - 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.

I would say "honor" the request, but basically that's what I
described. The signature should contain enough information for the
compositor to do the right thing. (On X that is just the refusal of
SetInputFocus with a timestamp earlier than the last setting of
focus.)


> 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).

As before, this is not what I described. In my description, the
compositor does not make requests of clients when doing things like
changing viewports, but clients can reject activation by withdrawing
the activated surface. See above for the rest.


> - The client cannot force anything to happen. It's request can always be
> ignored.

Yup.


> 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.

I think it's overstating to say I've put forth such a proposal. I
indicated some possibilities and my preference, but I was trying to
avoid putting forth a complete proposal. I was hoping to avoid what
you describe as my proposal for parity with X, on which conventional
clients do not use crossing events to request focus.

What you've described regarding sloppy focus--specifically, clients
that might activate only when the pointer is in a particular
control--is something I've never even seen suggested before. I think
it might be helpful if you provided a description of how a system with
such fine-grained sloppy focus would work and what the benefits would
be over other systems. Perhaps just email me privately or post a link,
if it's too off topic for this list.