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

[Deron Johnson]

Keith Packard wrote:
> Around 14 o'clock on Sep 14, Deron Johnson wrote:
> 
> 
>>Ok. Gotcha. But I'm still not understanding to overall rationale for
>>the multi-level redirection? How would this feature be used by applications?
> 
> 
> Imagine running looking glass inside croquet (or vice-versa).
> 
> -keith
> 
> 

I now understand what you're talking about. It sounds like you are
talking about a window which has defined for it client-specific
semantics about how events are propogated around inside it. This would
include client-specific semantics for propogation up the subwindow
tree as well as (possibly) client-specific grab semantics. If this is
not what you're talking about, please clarify further.

I can see how this would be useful for running an "In-a-box" style
embedded desktop, such as LG-in-a-box running inside of Croquet, or
vice versa. By "LG-in-a-box" I mean LG running inside of a flat window
which is itself living in a croquet room. This style of integrating
the two 3D desktop environments is a useful and necessary first
step. However, in the long term, I'd like to work toward a deeper
integration, such as Croquet object wrappers which would wrap around
LG objects and permit these LG objects to function as first class
citizens within Croquet. (This may involve integrating a Java VM into
Croquet). But like I said, this is longer term. LG-in-a-box would be a
good first step.

I can also see how the multi-level redirection feature would permit LG
to be integrated into a basic X server environment (where LG runs as
the primary desktop manager). The redirection feature would provide
the necessary "tap point" to extract events out of the server and send
them to the event manager (which is, in LG's case, called the Display
Server). The event manager would simply define a "redirection point"
on the root window (I'm assuming that the check for redirection points
starts at the root and works its way downward, right?) This feature
would also provide the necessary reinsertion mechanism to reinsert
events back into the server for further distribution to X clients.

It seems to me that the redirection client (e.g. the LG Display
Server) would need to be able to exercise some degree of control over
the type of event processing which occurs within the server after
event reinsertion. For example, in LG, I need to do all of the grab
processing in the redirection client. (This is necessary so that X
client grabs interoperate properly with 3D LG client grabs). So, after
my redirection client, reinserts the event back into the server, I
wouldn't want the server to start doing grab processing on its own. I
can see that there would be some types of input redirection
applications that would want grab processing to be done at this point,
but I would like the ability for the redirecting client to turn that
off.