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

[Gregory Merchan]

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

I did not know that when I suggested using the serials. The button,
key, and touch events all have timestamps, so if the notify_active
event also has a timestamp, the timestamps can serve as the signature,
just as they do on X.

Using the timestamp should also make it easier to sort out rogue clients.

Does Wayland have any of the issues that arise on X due to the latter
being asynchronous? I believe I still have notes somewhere on dealing
with those, though only for X, if they are necessary. It amounts to
little more than the compositor watching the timestamps, but there
were a few other needs for either clients or compostors which I cannot
recall right now.