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

[Jason Ekstrand]

On Tue, Oct 22, 2013 at 3:36 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> 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 see what you mean here.  However, I think apps doing this will cause more
trouble than it's worth.  One thing about current sloppy focus
implementations is that you can click anywhere in the window to raise it.
You want to change this.  However, what happens if that window is partially
obscured.  In your scheme, you would have to move the window so that the
magic text box is uncovered in order to raise it.  As is, if I want to see
said text box, I click the window to raise it so I can get to the text box.


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


I 100% agree with you here.


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


Yes, I agree it would be nice if you could select text without raising the
window.  However, I'd still like a way to raise it without having to click
a particular region.  That's an interesting UI problem


>   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 think the issue here is that the compositor must allow an application to
raise.  It must not raise unless instructed that it can by the compositor.
There also needs to be a consistent way for applications to know whether or
not they are allowed to raise.  If the only rule is "you have to be active
to raise" then a client can "take active" as soon as they see mouse
movement and then raise immediately afterwards.

Perhaps we could allow for some more flexibility if there was a way for the
client to reject an activation.  However, I still have the above fears.


>
>  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.
>
>
Yes, I like this.  I don't think it's feasible to try and keep some crazy
DAG.  As long as a client can atomically raise a bunch of windows we should
be ok.  A tree, whether or not it persists after the raise, will accomplish
this.


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

I still don't think these *should* be the same.  I understand that the
semantics are similar, particularly for popup windows.  That said, Kristian
has talked about removing the coordinates from "transient".  If we remove
the coordinates, then I'm not sure we even need "transient" as clients can
simply ensure that that window always gets raised with the parent.
Allowing clients to be in complete control of window stacking order (within
the client) would make a lot of things simpler.

Part of this is that I'm still not 100% happy with the fact that
subsurfaces don't get clipped to their parent.  (However, my feelings on
subsurface design are off topic here).  That said, If it were to change, it
would cause problems with using it for popups and things of the like.
Also, this would require all compositors supporting the xdg_shell to
support subsurfaces in order to have a useful shell.  Right now,
subsurfaces are optional..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131022/c1b90e8a/attachment.html>