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

[Bill Spitzak]

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