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

[Bill Spitzak]

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

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

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.

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