Input region support in the Shape extension

[Owen Taylor]

On Fri, 2005-01-28 at 09:17 -1000, Keith Packard wrote:
> Around 13 o'clock on Jan 28, Owen Taylor wrote:
> 
> > How does the Clip region come into play here?
> 
> The Clip region is purely for output; if the Clip region is different from 
> the Input region, then the application may have input areas which are 
> "invisible".
> 
> However, I see the Clip region as an anachronism now that we have ARGB 
> windows.  A clip region will force non-AA borders between the window and 
> the underlying content while an ARGB window provides for smooth blending.
> 
> And, ARGB windows have all of the same issues, without any way for the 
> server to easily notice which areas are transparent.
> 
> In Twin, I actually look at the window and pass mouse events through 
> transparent areas, but in X, I prefer the separation permitting 
> applications to capture input in transparent areas.

Or let through input in translucent areas. Makes sense.

[...]

> > Do you also need fixes for the usage of
> > [Xinerama]PointerInWindowIsVisible in WarpPointer?
> 
> Thanks for finding these.  I think this is right -- the assertion here is 
> that WarpPointer checks the source to assert that the pointer is currently 
> "inside" the window, which seems to now include the input region checks.
> 
> I've added the 5 line change to both of these functions.

What about the case where the point *is* in the window due to a hole in
the input region of some overlapping window? I don't quite understand
why the code in WarpPointer isn't just checking the ancestry of source
for sprite.win since the x/y being checked is just the pointer position.

(Whether anybody would notice in the remaining lifetime of the universe
if this was gotten wrong is a different question...)

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050128/e159f02c/attachment.pgp>