Re: Input event processing for translucent windows...

Sasha Vasko <[email protected]>
Newsgroups gmane.comp.freedesktop.xserver
Message-ID <[email protected]>
 > Here are (some of) the possibilities:
 >    1) make them like regular input/output windows.
 >       Problem: events go to the new window, even in large areas
 >       where you don't see them.

One of the examples where that makes no sense is numerous monitoring 
apps, that rely havily on being able to pass through events through 
"holes" in its shape.
	
 >    2) make them like output only windows.
 >       Problem: how do you get input when you want them.

Only very limited range of windows will be able to use this: splash 
screens, balloons, etc. Most windows do require input.

 >    3) make them do something fancier.  e.g.
 >
 >       If the pixel where the input event hits is fully transparent,
 >       deliver to the lower window; if even slightly translucent,
 >       deliver to the translucent window on top.

That is what SHAPE extention does nowdays. This approach makes sense, 
but also has very serious drawback: When pointer moves into transparent 
area Leave/Enter events has to be sent, and in case top level window is 
a menu - these events may trigger withdrawal of this window, which is 
completely undesirable.

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

It does not really make sense to send events to underlying windows if 
particular spot in top window is not completely transparent. User 
perceives blended image of underlying windows as merely a background of 
the top-level window, and will be surprised by events "leaking" through it.


Its seems that good solution might be to allow clients to control ( 
perhaps simple boolean flag) if events should be delivered to underlying 
windows, when pointer is in completely transparent spot, while always 
delivering events to top level window if its even slightly opaque.

One way of doing it would be to combine SHAPE extention and 
alpha-blending, where mask set with SHAPE defines areas where events 
should fall through, while everywhere else - delivered to top level 
window, event if its completely transparent.

 > In any case, this is fodder for thought and discussion...
 >                             - Jim


Sasha Vasko
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.