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

[Jasper St. Pierre]

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.


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


>> Once again, Gregory, Thanks for the explanation.  I hope I'm following ok.
>>> --Jason Ekstrand
>>>
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>
>>>
>>
>>
>> --
>>   Jasper
>>
>
>


-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131102/a969330e/attachment.html>