Input region support in the Shape extension

[Owen Taylor]

On Thu, 2005-01-27 at 21:27 -1000, Keith Packard wrote:
> I've hacked the Shape extension to expose an 'input' region for windows.
> 
> This is a region which is a subset of the Bounding region which restricts
> which portion of the window receives mouse events.  Portions of the window
> not in the Input region pass the mouse right on through to underlying
> windows.
> 
> It was amazingly easy to implement; about 15 lines of code.
> 
> The semantics seem obvious as well; in parallel with the Clip region it 
> limits the Input region to the intersection of the Input region, the 
> Bounding region and extents of the window.

How does the Clip region come into play here?

By "extents of the window", do you mean the "default Bounding region",
as defined in shape extension? 

> The only real questions are how I should advertise this new feature.  My 
> initial plan was to bump the Shape protocol version to 1.1 and leave it at 
> that.  There's no version negotiation in the current Shape protocol; the 
> client simply asks the server for the version, so we can't reject "old" 
> clients sending this new region name across the wire.  I figure that's 
> mostly harmless.

Sounds fine to me.

> The salient part of the extension is two copies of the following five 
> lines of code in dispatch.c and events.c:
> 
> +               && (!wInputShape(pWin) ||
> +                   POINT_IN_REGION(pWin->drawable.pScreen,
> +                                   wInputShape(pWin),
> +                                   x - pWin->drawable.x,
> +                                   y - pWin->drawable.y, &box))
> 
> wInputShape is a new macro which pulls the inputShape as defined by the 
> client out of the window extra record; the point here is in screen space 
> and so must be translated to window space before it can be compared with 
> the region.

Do you also need fixes for the usage of
[Xinerama]PointerInWindowIsVisible in WarpPointer?

> Other than this technical change, the remaining changes deal with managing 
> the region creation/destruction and the like.
> 
> I will probably just commit this change to xserver unless someone can 
> express significant concerns over its function or the method of 
> advertisement.

No objections here.

Regards,
						Oewn

-------------- 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/ae51332a/attachment.pgp>