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

[Bill Spitzak]

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.