[PATCH] Fixes v5: Cursor barriers

[Owen Taylor]

On Mon, 2010-12-06 at 09:41 -0500, Adam Jackson wrote:
> On Mon, 2010-12-06 at 06:27 -0500, Owen Taylor wrote:
> > 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.
> 
> The spec text could probably be a little clearer that the barrier
> coordinates are in screen space not window space, I think.

OK, then that's very much not clear from the text.

> > 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.
> 
> I was also trying to be unambiguous with GLX swap barriers.
> 
> > 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.
> 
> I suppose a pointer barrier is a stronger concept, since you may not
> have a cursor.  I hadn't really made any mental distinction between the
> two for barriers, since barriering an invisible cursor seems like very
> strange use case.

You always have a cursor right? It just can be a 1x1 invisible cursor? 
My thought process is more that it's XWarpPointer() or the confine_to
argument of XGrabPointer is documented as:

 'Specifies the window to confine the pointer in or None'

Another thought I had about the spec was that it probably should
explicitly mention that cursors only affect relative pointer devices and
not absolute pointer devices.

- Owen