On Tue, Nov 5, 2013 at 12:36 PM, Bill Spitzak <[email protected]> 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. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
