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

[Jason Ekstrand]

Bill,
Because I want to respond to everything in one e-mail, I'm going to try and
address your comments here even though they may not show up.

On Wed, Oct 30, 2013 at 3:19 PM, Rafael Antognolli <antognolli at gmail.com>wrote:

> Hi, I'm back to work on this, hopefully this time in a
> non-intermittent way. Some comments below:
>
> On Thu, Oct 24, 2013 at 12:00 AM, Bill Spitzak <spitzak at gmail.com> wrote:
> > Jason Ekstrand wrote:
> >
> >> At this point, I think I can propose a solution which should allow for
> >> client control while still keeping the compositor in control:
> >>  1) The xdg_surface has a pare of activate/deactivate events.  I think
> we
> >> need more than keyboard focus here because the user may not have a
> physical
> >> keyboard.
> >
> >
> > How does a client request an activation? And can it refuse an activation
> > from the compositor? Here is the sequence I see:
> >
> >  - Compositor sends some kind of "I want you to activate" to client
> >  - Client (if it wants to activate) sends an "activate" request. Clients
> > can also do this in response to mouse/key events without an activate from
> > the composiitor.
> >  - Compositor sends a "lost activation" to previous active client, and a
> > "gained activation" to the new client.
> >
> > As I see it the only reason the compositor will send the first event is
> due
> > to global shortcuts like Alt+Tab or some pager application, and
> destruction
> > of the current active client. If clicks or hovering is going to activate
> a
> > client, it is the client's responsibility to implement it.
>
> I'm sorry, but I fail to understand how a user could choose between
> click to focus, or sloopy focus, if that's up to the client to
> implement it. Wouldn't this lead to something like: if I use this
> video player A, but it only implements sloopy focus, and I want click
> to focus, I have to change to some other video player B?
>
> Again, sorry for my ignorance, I might have not completely understood
> your point.
>

Yes, in theory they could read the configuration of the compositor.
However, that's even more configuration syncing that we have to do and
anything other than the major 3 toolkits (Qt, GTK, and EFL) probably won't
bother.  They'll simply implement whatever focus model is easiest (or liked
by the developer) and they certainly won't go searching for special globals
and looking for config files for every compositor/toolkit.  I really don't
want to build this kind of inconsistency into the system and I don't see
why it's justified.

Also, why is a client, out of the blue, trying to take the focus?  The
compositor is going to have focus rules to prevent bad clients from doing
nasty things anyway.  Why not have the compositor tell the client when it's
allowed to have active.  This could be as simple as an activate request
with a take_active response.  Concerning semantics, I expect the activate
request to be sent whenever an event occurs on a non-active client that the
compositor deems activation-worthy.  This could include pointer enter,
pointer button, keyboard key, or nothing client-discernible at all
(alt-tab).

I would expect raise to act the same way (but I don't think we're debating
that one as much.


>
> > I still feel it is going to be identical to the keyboard focus for some
> > seat. A seat can have a focus even if it has no keyboard.
> >
> >
> >>  2) A request_raise event to which the client *can* respond with any
> >> number of raise requests.
> >
> >
> > Again exactly the same sequence. The compositor can send a "I want you to
> > raise" to the client, which it *can* respond to with raises. The client
> can
> > also raise itself in response to events. There probably does not need to
> be
> > feedback to the client whether the raise worked.
>

I think we agree here.  The compositor will have its own rules about when
the client can actually raise.  However, it should be able to re-order its
own windows at any time.


> >
> >
> >>  3) Both the request_raise and the activate events have a serial.  If
> the
> >> event corresponded to some user input (such as a mouse press) then the
> >> serial will match that of the input event.  Otherwise, it will have its
> own
> >> serial.
> >
> >
> > Yes. The compositor must be able to tell what event caused the client to
> > make the request. It can then ignore them, and solve race conditions with
> > multiple clients.
> >
> >
> >> Ok. I think I may be understanding transient windows better now (or
> maybe
> >> have come up with a good definition).  I think it's best seen in
> comparison
> >> to toplevel windows.  A toplevel window is "primary" in the sense that
> you
> >> expect it to have a button in the task bar, want it to show in expose,
> etc.
> >> A transient window, on the other hand, is one that is peripheral such
> as a
> >> dialogue box or the floating toolboxes in GIMP.  You don't want every
> >> transient window show up in expose mode or in the task bar.  In fact,
> you
> >> don't want it to show up except in relation to another toplevel window.
> >>
> >> That said, it is a very different concept to subsurfaces.  In
> particular,
> >> the client should not be able to always know where it is nor should it
> set
> >> it's location relative to another window directly. (This is different
> from
> >> popups).
> >
> >
> > Having written some applications, I absolutely want complete control over
> > where transient windows appear!!!! They must appear in correct positions
> > relative to the mouse cursor and to not obscure important information in
> the
> > main window. Also it is very useful to make fancy transient tooltips that
> > are hovering windows with pointers and that is not going to work if I
> can't
> > make the pointers point at things!
>
> I agree with you here, we have that exactly same use case in EFL. Not
> being able to set where the transient surface will be is going to
> prevent us to implement that behavior. Unless some other kind of
> surface should be used for this purpose.
>

One thing worth noting here is that the client doesn't know where the
window is, so it can't always properly place these transient windows (in
the case of toolboxes).  I know, Bill, that you have advocated many times
in the past that the compositor give the client the full transformation
matrix of the window at all times.  However I don't think this is going to
happen.  It wasn't my decision.  Let's not start that argument again here.
If we want to restore window positions (and I would like that eventually),
I think we can come up with some way of doing so that doesn't make the
compositor slave to the clients.

Now, concerning other pop-up type things such as tooltips, speech bubbles,
arrows, etc.  Perhaps they aren't the same as a standard transient window.
I would want a toolbox to not show up in a task bar (not toplevel) but to
also move independent of its parent.  Perhaps there is another category in
here.  Maybe we want four types: toplevel, transient (toolboxes etc.),
tooltip (position relative to parent), and popup (tooltip + grab
semantics).  It would be good to talk to Giulio Camuffo about this as he
spent quite some time banging his head on menus in Qt.


>
> > If the client tells the compostor to drag a window (due perhaps to a
> mouse
> > drag started in the window border) it is probably ok that the client does
> > not know where the window ends up (though it is really annoying because
> it
> > prevents clients from saving their window layouts).
> >
> > Also I see no reason that the client can't tell the compositor to drag a
> > subwindow as well. You are not convincing me that there is any
> difference,
> > the more I look at it the more I am convinced that these concepts MUST be
> > merged so that they each don't lack useful abilities the other ones have.
>
> I *think* that the reason behind it is that they have
> specific/specialized usage. Subsurfaces are specially for rendering
> things not in the main surface, but still merged in the same "window",
> so that the user would not see a difference, and have no way to know
> that there's another surface in there.
>

Yes! In particular, subsurfaces are a compositor-wide thing, where as
popup/transient/tooltip is entirely a *shell* thing.  Perhaps in some
compositor there is no distinction.  However, just because they look
similar in the scenegraph does not mean they are the same.


>
> Transient and popup surfaces have another semantic meaning, they are
> more like real windows.
>

Yes, they are real windows.  This also tells the compositor that the
surface is not actually part of the window.  For instance, it may not want
to render menus/tooltips in an expose mode.  However, subsurfaces would
have to get rendered in that mode because they are part of the original
surface.


>
> For a subsurface, there's no big reason to grab mouse pointer and so.
> On the other hand, it wouldn't make sense to synchronize the commit of
> a transient window with the one from a toplevel surface. At least from
> our toolkit point of view (EFL) it would make things more complicated
> IMHO.
>
> Of course they could all be merged, but then we would just end up with
> a big generic one surface to rule them all. Not sure if this is
> intended.
>

I really don't think we want one surface to rule them all.  There is also a
huge component-separation issue here.  I don't want subsurfaces to be 100%
a shell thing and I don't want grab symantics built into subsurfaces (or
window move symantics for that matter).  If we couple things too closely,
it's going to make it impossible to implement anything other than a desktop
shell with Wayland.  We DO NOT want that!


>
> Though that's only my current understanding, which is quite limited
> about Wayland so far.
>
> >> Given this understanding of transient windows, I'm less convinced that
> we
> >> need a window raise tree.
> >
> >
> > I *think* you are saying "there is no reason for the 'raise tree' to be a
> > different tree than the 'parent tree'". This is prehaps why I did not
> > understand what you were getting at. I never wanted more than a single
> tree,
> > and I thought Kristian was asking whether there should be *one* or *zero*
> > trees. Your email was about whether there should be *two* or *one* tree.
> I
> > want one, the same as you do, I think.
> >
> > So what I propose I think is the same as you are proposing: there is a
> > single tree (actually a forest), of parent/child surface relationships.
> The
> > "children" are sometimes called "transient windows", or "popup windows",
> > etc. This both communicates what window is the "parent" and makes map and
> > raise of the parents atomic with the children.
> >
> > If a client really has a reason to make the parenting different than the
> > raising it can temporarily rearrange the tree before doing a raise and
> then
> > put it back.
>

I'm pretty sure we agree here.  I see no reason for 2 trees either.  And I
do think we want some sort of a tree.  I think it's reasonable to make the
toplevel windows roots (no parent) and make all the other little window
types (popup, transient, tooltip) take a parent parameter which does not
have to be toplevel.  However, I would also like there to be some sort of
"commit" operation  so it can be don atomically.  One idea would be to
simply make that commit operation the same as the raise.

Thanks, I hope I addressed everything.
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131030/94022501/attachment.html>