On 10/22/2013 05:59 PM, Jason Ekstrand wrote:
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.
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
I think the clients can raise if the user clicks on a "dead" area where
the click serves no purpose. The most obvious is the window borders, but
also gaps between widgets and widgets that don't use click for anything
could raise the window.
It would still be possible for all the visible area of a surface to be
covered with buttons so there is nowhere to click to raise it. If this
is really a problem then perhaps the user holds down some shift key and
clicks?
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.
Absolutely a client must be able to "reject an activation". This would
be just like raise and focus: the compositor can only send a request
event to the client. The client must respond with an activate request if
it really wants activation.
However I think this may mean there is no difference between activation
and having a particular seat's keyboard focus.
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 think if the tree does not persist then it is identical to the "client
does a lot of raises atomically" version. This is however a possible
solution.
The only reason for the tree is so that other clients can examine it and
get some ideas about the relationship between surfaces. And also for
familiarity with other window systems. I think it may also be useful for
RDP to other window systems which may not have atomic sets of raises.
I believe these child surfaces and "subsurfaces" are
EXACTLY the
same thing.
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".
Not clear what he is getting at there. If the client can't position a
popup menu in the correct location it is pretty useless. I suspect he is
using a different definition of "transient" than I am.
Part of this is that I'm still not 100% happy with the fact that
subsurfaces don't get clipped to their parent.
I think clipping should be part of the buffer object. For instance a
block of shared memory can easily be "clipped" to a smaller buffer by
sending the correct stride and origin pointer. I hope (though I am
unsure) that this is possible with EGL buffers and other schemes being used.
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..
I believe that any compositor that can support the overlaid windows has
99% of the necessary code to support subwindows, and vice-versa. The
only difference is whether another surface can be inserted between them.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
