Re: Input event processing for translucent windows...

On Wed, 2003-11-19 at 09:32, Carl Worth wrote:
> On Nov 12, Jim Gettys wrote:
>  > One of the remaining bits of design we have to go through
>  > is the semantics of input event propagation of translucent
>  > windows.
>  >
>  > Here are (some of) the possibilities:
>  >    1) make them like regular input/output windows.
>  >    2) make them like output only windows.
>  >    3) make them do something fancier.  e.g.
> 
> 4) All of the above, (mechanism not policy and all of that).
> 
> And I think most of the mechanism is close to being there
> already. Keith is working out what needs to be done for OutputOnly
> which was missing.
> 
> SHAPE will still work fine for allowing the client to specify a region
> in which it wants to receive events. Perhaps we'll want to extend it
> in some way to allow "output only" portions of the window that are
> outside the region.
> 
>  >       An additional or alternate possibility would be to have some
>  >       sort of passive grab like mechanism, so that if the client
>  >       using translucent window on top wants, it would get
>  >       the event first, but be able to replay it to windows
>  >       underneath if it then wants.
> 
> This can be a very useful mode of operation. I've got code in xstroke,
> (which has been "faking" a full-screen translucent window for some
> time), to do mouse button replay. It uses the existing grab features
> as well as XTest and it seems to work fine.

Seems like formalizing this mechanism is in order, rather than
the back door kludge you did that is local only.
> 
>  >       Additionally, during the replay, one might be able to
>  >       translate/scale the event before processing, to make 
>  >       it possible for the event to go to some other window scaled
>  >       and translated in some fashion.
> 
> I think this is perhaps one of the most interesting new areas, and
> where new mechanism might be needed. Screen magnifiers, active
> thumbnails, and more crazy ideas for transformed window display all
> present situations in which the transformation between device and
> client coordinate systems are much more than the traditional
> translation. Should be a ripe area for research.

Yeah, I'm not quite sure what is right here right now.  It may be we
need to get some of these applications running before we understand what
is desirable.

This all gets very complex with things like Croquet, or what little I've
heard to date about LookingGlass; imagine your windows mapped onto
curved surfaces in a 3D world.  So I'm not sure  we can figure out the
right semantics without experimentation, though suggested possibilities
are in order.

To date, this work has not been what I consider research (beyond the
initial inspiration Keith had of the compositing approach): this input
mapping facility may require a bit.

Some of the Croquet folks will be visiting in a few weeks (in
particular, those who do the UI work), and I'll see if they have
insights then, if I can, since they've already been mapping squeak
applications into the Croquet 3D world, which brings up similar
issues.
                             - Jim


-- 
Jim Gettys <[email protected]>
HP Labs, Cambridge Research Laboratory