Click-to-focus and drag-and-drop (Was: xdg-shell: support background window actions)

I've substantially revised this to focus more narrowly on the problem.

The Problem

Beginning to drag a file icon or a selection from a background window brings that window to the foreground and may obscure the user's intended drop destination. The user then has to somehow bring the target window back into view while still engaged in dragging something. This could be much easier for the user if the initial button press on the drag source didn't activate or otherwise raise the source window.

Two Solutions

Regions

In keeping with the "descriptive not prescriptive" design of many Wayland protocols, a protocol might be devised to mark regions of a client surface as potential drag sources. A compositor could then wait until the user's intention is clear before activating a background window.

It seems to me a disproportionate solution to create a protocol just for one particular drag-and-drop situation in one focus mode, so perhaps there could be different kinds of regions for other "window management" functions. Where client-side decorations are used, the regions might map to the parts of the window that are parts of the decorations. This would allow the compositor to use the client-drawn edges and buttons without requiring a responsive application.

xdg-activation

The xdg-activation protocols gives clients a way to be more responsible for being activated, assuming the compositor allows it. An allowing compositor would not activate a surface in response to a mere button press, but would instead wait for an xdg-activation request from the client. Clients would have to always request activation when it is an appropriate response to a button press.