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