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

[Gregory Merchan]

On Sat, Nov 2, 2013 at 11:02 AM, Jasper St. Pierre
<jstpierre at mecheye.net> wrote:
> On Sat, Nov 2, 2013 at 11:50 AM, Jason Ekstrand <jason at jlekstrand.net>
> wrote:
>>
>> On Fri, Nov 1, 2013 at 11:36 PM, Jasper St. Pierre <jstpierre at mecheye.net>
>> wrote:
>>>
>>> On Fri, Nov 1, 2013 at 11:58 PM, Jason Ekstrand <jason at jlekstrand.net>
>>> wrote:
>>>
>>> ... snip
>>>
>>>>
>>>> Gregory,
>>>> Thank you very much for your e-mail.  I think that helps a lot.  The
>>>> lack of code is ok because I think Rafael is planning to start implementing
>>>> as soon as things settle a bit.  Sometimes protocol discussions can end up
>>>> with a whole lot of hypotheticals and what you gave was a very clear concise
>>>> discussion of the topic.
>>>>
>>>> If I am understanding you correctly, what we need are an "activate"
>>>> request and "notify_active" and "notify_inactive" events.  To support sloppy
>>>> focus, clients should just always try to activate on wl_pointer.enter and
>>>> let the compositor sort it out unless they have a good reason to do
>>>> otherwise.  For cases such as alt-tab, or another window closing, the
>>>> compositor simply sends a notify_active.  I think I'm ok with this.
>>>>
>>>> Two more questions that come to mind:
>>>>
>>>> 1) Will we ever need a deactivate request?  Under the given scheme, no
>>>> need comes immediately to mind.
>>>
>>>
>>> No. Well, if we need it, let's add it later.
>>>
>>>> 2) Should the activate be associated with a particular seat.  If you
>>>> have multiple cursors, you can easily have multiple active windows so this
>>>> seems perfectly reasonable.  If this is the case, should this be part of
>>>> wl_seat or should we keep it in xdg_shell?  I'm a little afraid to clutter
>>>> wl_seat unnecessarily but this is very quickly starting to look like a seat
>>>> focus.
>>>
>>>
>>> I don't think windows need to know which seat they're active on, only
>>> that they're active on possibly one of them. From my eyes, there's nothing
>>> that prevents the compositor to send "notify_active" to more than one window
>>> at the same time for multiseat support.
>>>
>>> If I click on an unresponsive window A, we'll send a "click" event to
>>> that window, but since it's unresponsive, it won't activate. I might then
>>> decide to activate another window B, which will respond. When the window A
>>> becomes responsive again, it will process the "click" event and decide to
>>> send an "activate" request back. We need to make sure that this "rogue"
>>> client doesn't steal the focus, so the compositor needs to record the serial
>>> for the last "activate" event it got (sent by window B), and compare against
>>> it when it gets an "activate" event, besides whatever policies it might
>>> have.
>>
>>
>> Here is the problem.  Say you have two pointers P and Q and two and two
>> windows A and B.  P clicks on A and A a is now active.  Q clicks on B and
>> now B is active.  Then P goes and clicks on B.  However, B is already active
>> so it doesn't request an activation and A stays active with pointer P.  This
>> assumes we are trusting clients to request activation.  The other option is
>> that we simply force a click-always-activates model and clients are
>> constantly fighting the compositor just to make modal dialogues work.
>
>
> "Already active"? All "notify active" means is "please draw me with a
> focused frame". The client should send an "activate" request on every button
> press if it wants to be focused when something clicks on it.
>
> As has said before, click-always-activate is broken: if I have window A
> activate, and I want to drag something from window B onto window A, we
> shouldn't activate window B on click.

We should trust clients to request activation when it is appropriate
for the client; appropriateness is distinct from having a valid
signature from the request.

It is in the self-interest of clients to request activation when
appropriate, so we would be trusting them to act in their
self-interest. This is usually a safe bet. Clients not acting in their
own interest--failing to request activation--will not appeal to users,
and evolutionary pressures may take their course.

The beginning of a drag is not the only event which a client may deem
inappropriate for activation. A client, such as a drawing program,
with a free-floating palette would want for its primary window to
remain active when toggle buttons on the palette are clicked. A more
complicated program might have a palette with non-window-activating
toggle buttons, but other controls which are window activating.

Clients may allow their scroll bars to be used without activating a
window. I think most X-based systems and MacOS send scroll wheel
events to the window under the pointer, and non-window-activating
scroll bars would allow the same function to people without or unable
to use scroll wheels.

Most client authors will use a toolkit, and that toolkit can make the
right behavior easy. The default callback for a button press on a
toolkit widget might request activation. The default for scroll bars
might then override the widget default to allow the aforementioned
use. The default for a text area would override to determine if the
event could be the beginning of a drag and act accordingly. I suppose
a callback system is not necessary; a boolean property like
'activatesWindowOnButtonPress' might be used instead, then the event
handlers can do what they need to do. The default could go either way;
I think Cocoa defaults to not activating and overrides in almost every
subclass.

A sometimes convenient way to handle some of this on X is to rely on
button event fall through. Where the client expresses no interest in
button events, they fall through to the window manager's frame window
and the window manager is then responsible. I don't think there's a
similar thing in Wayland, so that may be irrelevant. I think there is
something like this in Cocoa, but it's been to long since I grokked
that.

Trusting clients to activate is more a matter of trusting the
toolkits, and there are few enough of those to apprise authors of what
is expected.

>>> But serials are seat-specific, so we need the "activate" request to relay
>>> the seat back for the purposes of validating the timestamp. I don't think it
>>> makes sense to expose the active window on wl_seat, though.
>>
>>
>> That's not correct.  Timestamps are seat specific but timestamps are not
>> the same as serials.  Timestamps are local to the seat.  Serials are
>> actually compositor-global in weston and, in order to make things work,
>> should probably at least be client-global in other compositors.
>
>
> I thought serials were intentionally *not* client-global, as we often
> compare serials from two different clients. But whether they're seat-global
> or compositor-global is something the specification doesn't say. We should
> probably clarify that somewhere.

Whatever is used for the signature, I think the most important thing
is to keep an ordered global sequence, so old signatures don't cause
focus stealing. The rest of signature validation is the second most
important thing. I would place third the ability to transfer valid
signatures, as I described in an earlier message.

I mentioned Cocoa because I remember there being something in it for
handling activation--as an example of what a toolkit might do--but I
can't remember it or find it at the moment; maybe GNUstep had the
documentation? I did run across Apple's guidelines for active,
inactive, main, and key windows, and that may be of interest:
https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/Windows/Windows.html#//apple_ref/doc/uid/20000961-SW8