On Mon, Nov 4, 2013 at 4:44 PM, Bill Spitzak <[email protected]> wrote: > Gregory Merchan wrote: > >> The only difference I understand between the active state and having >> the keyboard focus is that a keyboard grab may take away the focus but >> should not deactivate the window. > > > Grabs don't change the keyboard focus. Instead the client that did the grab > knows it has the keyboard until it loses it. There are no focus-lost events > sent to the previous surface with focus, it just won't see any events during > this time. > > In reality the client doing the grab is going to already have the keyboard > focus. Otherwise the compositor probably would not have allowed it.
I only know X grabs, which do change keyboard focus, so on the off chance that Wayland works the same way I say "a keyboard grab _may_ take away focus". >> In the code I was writing for X over >> a year ago, I made use of the mode field in XFocusChangeEvent to >> decide whether to treat a window as deactivated; as I recall, there is >> always a NotifyNormal focus change mode when focus really goes away. > > > I would avoid this annoyance by sending only focus/active on events to a > client if already has the same state on another surface. A focus/active-lost > event always means a *different* client got it. I was just describing a trick for X, in case it was relevant. >> Sloppy focus, as a system-wide policy, can be handled by the >> compositor without the assistance of client. It would activate the >> window whenever the window would receive a wl_pointer::enter event. Am >> I misunderstanding how events are handled? > > > 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?) >> 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. > > > Now that is an excellent idea, and gets rid of the need for the compositor > to send activate-request events on mouse enter. A simple client basically > activates itself in response to every mouse enter or click event. The > compositor has a setting whether point-to-type is on, and if it is off it > ignores the requests on mouse enter. And it's an idea that fits in with the 5th policy I described: the compositor has no special conditions for activation, only the general conditions shared across policies (like viewport changes) and responding to requests. I personally don't like the idea of clients requesting activation on crossing events, in part because it means more cross-platform differences, but since the compositor can filter requests according to event-based signatures, we can all have our way. >> I believe you are, so I'll throw something else at you. The signature >> should be something that can be passed from one program to another >> either as an execution argument or in the environment. > > > I'm not sure this is the same thing, but I would like to see the ability of > a client to pass the ownership of any object it creates to another client by > passing some kind of signature (which cannot be forged because it is an > encrypted value supplied by the compositor). This would avoid the current > hair in making another client produce a subsurface, what I propose is the > *parent* create the subsurface, sets it up exactly how it wants, then gets > the signature from the compositor and passes this on the argv to the child > process. The child process then uses this in a "take this object" api and > the object is transferred to it. > > >> I just remembered another reason for activation to be distinct from >> keyboard focus: a desktop environment may want to regard a toplevel >> window as still active when one of its secondary windows (e.g. a modal >> dialog) has keyboard focus. > > > Actually this is relevant if the two windows belong to different clients, as > you propose above. If they belong to the same client I figured the client > would just act as though the child got the keystrokes even if the compositor > sent them to the parent. _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
