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

[Rafael Antognolli]

On Thu, Oct 31, 2013 at 12:42 AM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> 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.

Yes, either implementing the easiest, or the one that they think it
makes more sense. Or, if they do want to read configuration and
implement everything correctly, it will be a lot complexity.

On the other hand, the compositor having the logic of when it should
focus a window, and sending such event to the client, simplify things
in the client. But that does not prevent the client to request focus
at any time, when a mouse movement is detected, or some other kind of
event. Which kind of gives flexibility to the client to implement any
special behavior.

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

OK, I wasn't thinking about anything to allow/prevent a client to take
focus, but that can be done too. Do you think we can go with a simpler
approach (not preventing anything), and add that later, just to
finally start things and have something working soon?

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

This looks good to me.

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

I don't agree with this, but fine, let's do the simplest first.

So, what about this: I add only the expected surface types (toplevel,
transient, popup), transient should have no way to set its position.
Later, if we find it necessary, we can either add a new type, or add
an API to set transient's position? It would at least postpone this
discussion, or maybe we even move it to another thread, specific to
this topic.

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

That makes sense to me.

> Thanks, I hope I addressed everything.

I'll try to come up with a protocol spec for that, and we can keep
working on fine tuning it if you agree.

-- 
Rafael Antognolli