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 <[email protected]> > > > > 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
