[PATCH] Fixes v5: Cursor barriers

[Owen Taylor]

Reviewed-by: Owen Taylor <otaylor at fishsoup.net>

This looks good to me - it look like it is sufficient to meet the need
of making easy-to-hit "hot corners" on a multi-head displays with a good
amount of flexibility but without adding a lot of unmotivated
complexity.

Creating barriers relative to any window rather than to a root window
isn't needed for the hot-corner case, but since the Window argument is
needed to say *which* root window in the multi-screen case, it seems
natural to allow any window.

There's a slight naming iconsistency in CreateCursorBarrier vs. the
Barrier resource, but that's OK - resources are almost all one word
but CreateCursorBarrier is more self-documenting than CreateBarrier.

Though I do wonder, is this a Cursor barrier or a Pointer barrier? I
always thought of the cursor being the image displayed at the mouse
pointer.

> +************* XFIXES VERSION 5 OR BETTER ***********
> +
> +12. Cursor Barriers
> +
> +Compositing managers and desktop environments may have UI elements in
> +particular screen locations such that for a single-headed display they
> +correspond to easy targets according to Fitt's Law, for example, the top
> +left corner.  For a multiheaded environment these corners should still be

single-headed versus multiheaded

> +semi-impermeable.  Cursor barriers allow the application to define
> +additional constraint on cursor motion so that these regions behave as
> +expected even in the face of multiple displays.
> +
> +WarpPointer and similar requests do not obey these barriers.
> +
> +12.1 Types
> +
> +	BARRIER:	XID
> +
> +	BarrierDirections
> +
> +		BarrierPositiveX:	    1 << 0
> +		BarrierPositiveY:	    1 << 1
> +		BarrierNegativeX:	    1 << 2
> +		BarrierNegativeY:	    1 << 3
> +
> +12.2 Errors
> +
> +	Barrier
> +
> +12.3 Requests
> +
> +CreateCursorBarrier
> +
> +		barrier:		    BARRIER
> +		window:			    WINDOW
> +		x1, y2, x2, y2:		    CARD16
> +		directions:		    CARD32
> +
> +	Creates a cursor barrier along the line specified by the given
> +	coordinates on the screen specified by the given Window.  The
> +	barrier has no spatial extent; it is simply a line along the left
> +	or top edge of the specified pixels.
> +
> +	The coordinates must be axis aligned, either x1 == x2, or
> +	y1 == y2.  If not, BadValue is generated.

Should specify what the meaning if x2 < x1 or y2 < y1 is. Is it
BadValue, or empty, or the same as the unreversed case. If x2 < x1 is
BadValue then should specify whether x2 == x1 is BadValue or not, but
doesn't seem necessary if all x1,x2 pairs are legal.

> +
> +	Motion is allowed through the barrier in the directions specified.
> +	Nonsensical values (forbidding Y axis travel through a vertical
> +	barrier, for example) and excess set bits are ignored.

Might be good to actual say what "in the direction specified" means. The
only documentation is the constant names and while you can guess that
BarrierPositiveY means crossing the barrier in the direction of Y
coordinate increase (down), it's not entirely obvious.