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

[Bill Spitzak]

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.