[PATCH] Fixes v5: Cursor barriers

[Adam Jackson]

On Mon, 2010-12-06 at 09:59 -0500, Owen Taylor wrote:
> On Mon, 2010-12-06 at 09:41 -0500, Adam Jackson wrote:
> > On Mon, 2010-12-06 at 06:27 -0500, Owen Taylor wrote:
> > > 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.

Can we think of a need for window-relative barriers?  It seems neat, but
not especially useful, and it's not what I have implemented.  Barring
that, should the spec explicitly require a root window, just so we can
add window-relative later if we find a need for it?

> > > 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'

Yeah, seems worth being consistent here.  Will amend.

> 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.

Yes, that's definitely the intent.  It's mentioned in the Create request
definition but probably belongs in the top-level rationale.

- ajax