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

[Jasper St. Pierre]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131102/290992b4/attachment-0001.html>