MPX and Enter/Leave events

[Peter Hutterer]

On Fri, Aug 08, 2008 at 03:28:33PM -0400, Owen Taylor wrote:
> But that neglects the fact that X allows not just tracking whether
> the pointer is within a window itself: it also allows tracking whether
> the pointer is within a descendant. So, the above statement is not
> sufficient to allow us to determine coherently what events should be
> delivered to a window, and what the detail fields should be.

correct, the current solution was intended more to track movements than to
track position and largely devised through trial-and-error.  
I was never quite happy with the current implementation anyway, so I'm
delighted about a replacement.

> What I would propose as a better solution is to say that for the
> purposes of delivering events to a *single* window W, we should 
> generate events as if the pointer window was determined as follows:
> 
>  If there is at least one pointer located on the window itself,
>  not counting the subwindows, the pointer window is the window 
>  itself.
>                                                                                                                                                                                                   
>  Otherwise, if there is at least one pointer located within a 
>  descendant of W, then the pointer window is the descendant
>  containing the descendant with the highest priority pointer.
> 
>  Otherwise, the pointer window is the window with the highest
>  priority pointer.
> 
> This involves putting an arbitrary priority, ordering on the pointers
> but it will turn out that it has very little impact, and only
> affects what gets put into the 'subwindow' field of crossing events.

We already have a "hierarchy", imposed by the pointers being in a linked list.
The "first one wins" principle would apply here, and work fine for most cases.
We can't really use the ClientPointer here, as at the time of event generation
we don't know the receiving client. but as you said, the hierarchy doesn't
matter much anyway.

> What holds, given the above definition, is:
> 
>  When a pointer moves from one window A to another window B, the
>  events generated are a subset of the events generated in a classic
>  X server for the single pointer moving from A to B, in the following
>  sense:
> 
>   - The events are sent to the same window
>   - The events are sent are of the same type (enter or leave) 
>   - In some cases the event may be suppressed
>   - In some cases the detail field may be changed
>   - In some cases the subwindow field may be changed
> 
> The full case-by-case analysis is appended to the end of the message.

Thanks for that. From what I can tell, it is sound and should work - even for
grab/ungrab cases. I have to look at the server and how long it'll take me to
implement the proposed approach. I don't want to give you a timeline just yet
though, in case I can't hold to it.
 
Cheers,
  Peter