[PATCH 2/2] protocol: add state set functions for maximized and fullscreen.
spitzak at gmail.com
Thu Oct 31 21:37:25 CET 2013
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).
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
> 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".
More information about the wayland-devel