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

[Bill Spitzak]

Jason Ekstrand wrote:

> I think I would disagree on this one.  As an avid sloppy-focus user, I 
> really don't want apps arbitrarily deciding that they are 
> click-to-focus.  While some things (look and feel) are entirely 
> cosmetic, if how apps get focus is app-dependent, it will drive users 
> crazy.  I think the bigger issue here is to allow for different modes of 
> focus.

I also use sloppy focus all the time, which is why I *want* my proposal. 
I see it as the opposite: I am allowing a client to be sloppy focus 
whether or not the compositor thinks it should be.

Also for any focus model, my primary concern is that I want to allow the 
areas that cause the focus to change to not have to correspond to the 
edges of surfaces. In sloppy-focus it could help a lot if you had to 
point at the text box, rather than the toolbar or border or a control 
panel, to get the focus.

> I think the big thing here is that we need to allow for a distinction 
> between "active" and "raised" and the compositor should be in rough 
> control of both.  I say rough because the client may want to raise 
> additional windows (such as toolbars) and it is impossible for the 
> compositor to know exactly what the client will want to raise.  
> Therefore, I'm a big fan of the compositor sending a request_raise event 
> and the client responding with a series of raise requests (similar to 
> the method recommended for handling window states).

Yes I agree mostly. Absolutely "active" and "raised" must be 
independent. However I now do not think there needs to be any difference 
between "active" and the keyboard focus for a particular seat.

The compositor must NEVER NEVER NEVER either raise or activate a 
surface. It can only send request events to the client. The client can 
then produce actual raise and activate actions. The only thing a 
compositor can do is ignore these if it thinks they are inappropriate.

> Most window managers I've seen have three basic window focus models:
>  1. Click to focus

My proposal would allow the focus to change depending on what the user 
clicks on.

>  2. Focus follows mouse, click to raise

My proposal (and I think everybody's proposal) would allow the client to 
decide if a click raised the window. In particular it would allow you to 
hit buttons and select text without raising the window, but clicking to 
move the insertion point or draw would raise it.

>  3. Focus follows mouse, click or hold mouse above window for a short 
> time to raise.

I think again this could be client responsibility. Though I would have a 
"hover event" sent from the compositor, so that the timeout can agree 
between all clients.

> Bill, Allow me to more directly respond to the suggestion for 
> take_active that you described above.  The problem isn't so much a 
> configuration issue.  More to the point, in order to support all three 
> of the above modes, we have to allow a client to get keyboard focus and 
> raise to the top without clicking.  If things are handled in terms of 
> take_active then clients will be able to raise themselves if the user so 
> much as brushes the mouse across them.  I don't think we should allow 
> clients to do whatever they want as soon as they get a mouse.  There may 
> be a way to solve this, but it's not presenting itself immediately.

To do sloppy focus, the client would respond to a mouse-enter event by 
requesting activation/focus. I'm not sure why you don't think sloppy 
focus works under what I propose.

Activation would *NOT* raise the surface, unless the client wants it to.

> I would agree that some sort of a tree is probably a good idea if for no 
> other reason than it makes raising atomic.  One idea would be to treat a 
> xdg_surface.raise request like a sort of commit.  The client would make 
> a bunch of xdg_surface.place_above (or some other name) requests to 
> build the tree and then call xdg_surface.raise on the root of the tree 
> to raise the whole tree.  After that we could probably discard the 
> place_above relationships and let the client rebuild them for the next 
> raise.  Not that that's really necessary but, as long as we allow 
> clients to modify stacking at times other than a full activate/raise, I 
> don't see how useful keeping the tree would be all that useful.

This is the first proposal I said, echoing Kristian's first proposal. 
Basically the client is entirely in control. There really does not need 
to be any tree, just an atomic sequence of raises with a commit. I think 
this should always work in Wayland.

The "tree" I propose is so that pager clients can have a clear idea what 
the relationship between surfaces are. The problem with current trees 
such as in ICCCM is that they end up really really complex, because in 
fact what is wanted is a directed acyclic graph (more than one parent 
per surface, this is attempted with "window groups" in ICCCM). I propose 
this be avoided by:

The client can always change the tree whether or not the surfaces are 
mapped. Changing the tree has no visible effect even if the current 
stacking is "wrong". Surfaces are only raised by requests from the 
client, so the client can always rearrange the tree before raising.

>     I believe these child surfaces and "subsurfaces" are EXACTLY the
>     same thing.
> 
> The problem here is that subsurfaces are a compositor-wide thing while 
> transient and popup are shell things.  Popup involves extra pointer 
> symantics. (I still don't fully understand transient)

That's what I'm complaining about. Wayland currently has two 
implementations of a lot of stuff, depending on whether it is a floating 
  window or subsurface, even though these look and act IDENTICAL unless 
you manage to get another surface from another client in-between the 
floating window and it's parent. That is bad design. And there is no 
reason subsurfaces are denied the "extra pointer symantics", and no 
reason floating windows are denied all the sync work done for 
multi-client subsurfaces.

I am using the word "transient" to mean a surface that stays above it's 
parent, but otherwise has no effect.

"popup" seems to mean an atomic mapping of the window and pointer grab, 
and possibly automatic unmapping when clicked outside? I think Wayland 
is being excessively complex. I think somehow doing the grab before the 
map would work to make them atomic. Instead of unmapping, I would have a 
press outside the grabbing surface followed by a release cancel the 
grab, but only after reporting the events as normal to the grabbing 
surface. And the "popup" is unmapped by the client, not because it lost 
the grab. In any case there really should be no difference between 
transients, popups, and clients grabbing the pointer.

And it would be really nice if all this worked for subsurfaces.