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

[Bill Spitzak]

Jason Ekstrand wrote:

> I still don't understand why a client would want to not activate.  I can 
> see not wanting to raise, but why not activate?

The main one I see is you do not want attempts to drag an object to 
activate the drag-from client, since this may unmap the desired target 
of the drag since it belongs to the former active client. Dropping would 
activate the dropped-on client.

I also feel like point-to-type could be helped by this, though I am 
unsure how. The main reason is that "sloppy focus" could be considered 
the desktop refusing to take focus when the cursor enters it.

>     - Show in task bar (I'm not convinced this is ever wanted)
> 
> Why not?  Maybe we're missing each other on this one.  By "show in task 
> bar" I don't mean as a tray icon.  I mean that it's toplevel and it 
> shows up as an independently user-activateble window.

What I meant was I don't know if it is ever wanted for non-toplevel 
surfaces to show in the taskbar. Thus the flag may not be needed since 
whether or not the surface has a parent controls this.

If there is a desire for top-level surfaces that are not in the taskbar 
then a flag will be needed. If transient windows should be in the 
taskbar then the client could just do the raises itself, but it may be 
useful to have the flag then as well.

> *if* we decide to go with flags, I would recommend a 
> set_relative_position request and an unset_relative_position.  Attaching 
> a buffer with a non-zero x and y would change the position but otherwise 
> leave the lock intact.  The xdg_shell.move request or anything similar 
> would automatically release the lock.  Does this seem reasonable?  
> Another option would be to just set it at (0, 0) relative to the parent 
> and use the next buffer attach to determine the position.

Actually that (the 0,0 idea) sounds like a very good idea and in keeping 
with the design of the rest of Wayland.

There will probably need to be scaling and other affine transforms as 
well, but these are needed for subsurfaces and top-level surfaces. In 
any case it would be cleaner if transforms were different requests 
rather than having to put the entire transform on the map call.