Jason Ekstrand wrote:
Yes, in theory they could read the configuration of the compositor.
I really don't want to build this kind of
inconsistency into the system and I don't see why it's justified.
I think I see what you are getting at. I think a scheme that allows
simple applications to obey the global setting without thinking, but
still allows applications that have a good reason to do tricks with the
focus, and also matches the raise proposal, is this:
- The compositor sends an "I want you to activate" event, as you propose.
- The client can respond to this with an "activate" request. Or it could
send an "activate" request at other times if it wants.
- The compositor responds to the "activate" request by either ignoring
it or actually doing the activation.
- The compositor sends an "activated" event that the client can respond
to by redrawing to show the fact that they are activated.
If a client just echoes the "I want you to activate" event then it will
work as you expect. A client could also wait after the event until the
mouse enters a correct location or clicks on the right thing. It could
also try to generate spurious activates but the compositor may ignore them.
I agree with you here, we have that exactly same use case in EFL. Not
being able to set where the transient surface will be is going to
prevent us to implement that behavior. Unless some other kind of
surface should be used for this purpose.
One thing worth noting here is that the client doesn't know where the
window is, so it can't always properly place these transient windows (in
the case of toolboxes).
The location of transient windows is *relative* to the parent's
transform, not absolute.
There are already proposed and implemented apis to discover if a
rectangle in the parent's space is clipped by output edges and panels,
so a client can choose a different rectangle.
I know, Bill, that you have advocated many
times in the past that the compositor give the client the full
transformation matrix of the window at all times. However I don't think
this is going to happen. It wasn't my decision.
Yea I give up on this as well, and relative transforms of transient
windows avoids this problem for now.
Now, concerning other pop-up type things such as tooltips, speech
bubbles, arrows, etc. Perhaps they aren't the same as a standard
transient window. I would want a toolbox to not show up in a task bar
(not toplevel) but to also move independent of its parent. Perhaps
there is another category in here. Maybe we want four types: toplevel,
transient (toolboxes etc.), tooltip (position relative to parent), and
popup (tooltip + grab semantics). It would be good to talk to Giulio
Camuffo about this as he spent quite some time banging his head on menus
in Qt.
I think this will have to be a bunch of flags or you will end up with
2^N different window types. Flags I can see:
- Locked transform (whether the window moves when the parent does)
- Show in task bar (I'm not convinced this is ever wanted)
- Show in thumbnail (may be same as locked transform?)
- Whether it is a subsurface, or a window, or a window above the panels.
- Clipped to parent (this has been requested a bunch and may be
necessary if client cannot absolutely control the location).
- Grab
The current grab I don't like. It seems that the surface is always
unmapped on a click outside it. Also there is an entire somewhat
parallel grab mechanism for normal surfaces. I am pretty certain this
can and should all be merged. A popup transient would be a normal
transient except the client also grabs the pointer. Losing the grab
would work like Windows (if press + release are both outside the grab
surface then the grab is cancelled after the release is delivered to the
client).
I do think we want some sort of a tree. I think it's reasonable to make
the toplevel windows roots (no parent) and make all the other little
window types (popup, transient, tooltip) take a parent parameter which
does not have to be toplevel.
This sounds identical to what I want.
However, I would also like there to be
some sort of "commit" operation so it can be don atomically. One idea
would be to simply make that commit operation the same as the raise.
As I see it, the client can change the tree all they want with no
visible effect (even though the current stacking may be "wrong"). The
only thing the tree does is that when a raise happens, it also
atomically raises all child surfaces along with it. Thus the raise acts
as the "commit".
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
