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

[Bill Spitzak]

Gregory Merchan wrote:

> The beginning of a drag is not the only event which a client may deem
> inappropriate for activation. A client, such as a drawing program,
> with a free-floating palette would want for its primary window to
> remain active when toggle buttons on the palette are clicked. A more
> complicated program might have a palette with non-window-activating
> toggle buttons, but other controls which are window activating.

The client itself is probably active and can activate it's main surface 
and not the toolbox on clicks. I think compositors should allow a client 
to claim any surface is the active one as long as it thinks some surface 
belonging to the client can be active.

> Clients may allow their scroll bars to be used without activating a
> window.

This is a great example and shows that drag & drop is not the only place 
that clients should be responsible for activation.

> Most client authors will use a toolkit, and that toolkit can make the
> right behavior easy.

Yes, toolkits are the proper place for setting the "this widget works 
this way" controls. The problem with X and Windows (and maybe OS/X) is 
too much of this setting must be communicated to the compositor through 
some kind of ipc, slowing down initialization, making it sometimes 
impossible to change the settings, and adding a huge amount of 
complexity to the api.

> A sometimes convenient way to handle some of this on X is to rely on
> button event fall through. Where the client expresses no interest in
> button events, they fall through to the window manager's frame window
> and the window manager is then responsible. I don't think there's a
> similar thing in Wayland, so that may be irrelevant. I think there is
> something like this in Cocoa, but it's been to long since I grokked
> that.

Wayland provides the compositor move + resize api. The client calls this 
in response to button clicks in window borders. This is pretty much the 
"fallback" api.

I think this could be improved a little by adding this:

1. A way to tell the compositor to choose whether to drag or resize, and 
what borders, based on the mouse position. This is to allow the 
compositor to be in charge of how thick the resize edges are.

2. Another call to "preview", indicating that the current mouse position 
if clicked will in fact cause the move/resize api to be called. The 
compositor can then change the cursor or highlight the edges to show 
this. There also has to be a way to turn this preview off.

In the end I hope this will get rid of the need for resize edges and 
title bars to take any pixels. Clients will just have to make sure there 
is some place near the edges that when clicked cause the move/resize api 
to be called. Compositors will still be in control of window edge 
snapping, etc.