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

[Gregory Merchan]

On Mon, Nov 4, 2013 at 4:44 PM, Bill Spitzak <spitzak at gmail.com> 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.