[Xevie] Re: Invitation to a discussion about an External Event Manager

[Deron Johnson]

Keith Packard wrote:
> Around 12 o'clock on Sep 14, Deron Johnson wrote:
> 
> 
>>Of course, keyboard processing has the additional wrinkle that if it 
>>doesn't find what it is looking for in the focus trace then it searches
>>the sprite trace downward from the root down to the current pointer 
>>window.
> 
> 
> Kinda; it searches down the focus trace until it his the bottom, and then 
> walks down the sprite trace if the two are the same at that point.  The 
> point is that our redirection should follow the same path.
> 
> 
>>>	1) Events sent to grabbed devices *still need redirection*, if the
>>>	   grab window is a descendent of a redirection window.
>>
>>Do you mean "events sent FROM grabbed devices?" Events don't get sent to
>>devices; they get sent to clients.
> 
> 
> heh.  From inside the X server, it's more like events are sent *to* 
> devices (where the 'device' is the X server abstraction, not the physical 
> entity).  In any case, events delivered while a device is grabbed should 
> still be subject to redirection.
> 
> 
>>Are you defining a "redirection window" as a window for which 
>>redirection is enabled?
> 
> 
> yes.
> 
> 
>>Should Enter/Leave events be generated if the redirection client alters
>>the event to put it into a different window?
> 
> 
> Yes.  Any pointer motion should generate appropriate crossing events.

Ok. Gotcha. But I'm still not understanding to overall rationale for
the multi-level redirection? How would this feature be used by applications?