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

[Bill Spitzak]

Rafael Antognolli wrote:

> I'm sorry, but I fail to understand how a user could choose between
> click to focus, or sloopy focus, if that's up to the client to
> implement it. Wouldn't this lead to something like: if I use this
> video player A, but it only implements sloopy focus, and I want click
> to focus, I have to change to some other video player B?

The clients are expected to pay attention to user configuration 
settings. This is also how they all use the same fonts and colors, etc.

> For a subsurface, there's no big reason to grab mouse pointer and so.

Actually there is if the subsurface is being managed by a different 
client and it wants all the events even if the subsurface was created by 
the parent client.

> On the other hand, it wouldn't make sense to synchronize the commit of
> a transient window with the one from a toplevel surface. At least from
> our toolkit point of view (EFL) it would make things more complicated
> IMHO.

It would be useful for making lines connecting the transient windows or 
when they are arrows pointing at something in the main window.

> Of course they could all be merged, but then we would just end up with
> a big generic one surface to rule them all. Not sure if this is
> intended.

That is my intention. I believe this will simplify Wayland considerably 
by merging two different implementations of what is actually, as far as 
a compositor is concerned, two identical things.