Input event processing for translucent windows...

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.

 >       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.

-Carl