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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
