Re: considering modifier keys after gaining focus

[Oliver Schmidt <oschmidt-mailinglists@gmx.de>]

Hi Jon,

On 1/11/2012 6:16 PM, Jon TURNEY wrote:
> I think it is useful to consider this history when reviewing a patch, 
> Are we going in circles?  Are we doing in the wrong direction? 

I appreciate your carefulness und thoroughness. It's of course always
better to understand what is going on, especially in a large code base
with a long history.


> Anyhow, in a brief look at some mailing list discussions from 2002 or so, it
> seems that:
> i) We must release modifier keys when focus leaves the X server, as modifier
> keys may be part of a Windows shell shortcut which moves the focus elsewhere,
> e.g. alt-tab) so the key-release isn't received by the X server.

Ah ok, so my guess was in the right direction ;-)


> ii) We must release non-modifier keys when focus leaves the X server, or they
> continue to auto-repeat in the X server (specifically a problem when a
> key-press closes a window (such as typing ctrl-d or exit into an Xterm), as
> the key-release goes to the next window to receive focus, which may not be an
> X window)

Interesting, I didn't know this. Thank you for figuring this out from
the malinglists archives.


> iv) What should we do about held non-modifier keys when focus enters the X server?
> 
> It looks like these should be pressed as well for strict correctness.  If we
> hold down a non-modifier key so it auto-repeats, and move the focus between X
> and native windows, the native windows receive repeats, but the the X windows
> do not.  I doubt many people care about this behaviour, though :-)

Yes, you are right: I can reproduce this phenomenon by holding down
Ctrl+N for opening windows and the key is not autorepeated (so only one
window is opened, whereas under Linux xserver many windows are opened).

In my daily usage I didn't discover this phenomenon. My patch only
addresses the problem, that the modifier keys are not right after
keyboard driven focus change, disrupting my workflow. So I agree that
there might not many people caring about this behaviour.


> Hm... on looking at this again, isn't that code you are adding checking the
> internal state of non-latching modifiers bogus?  If we release all keys on
> WM_KILLFOCUS, then the non-latching modifiers will always be clear when the
> WM_SETFOCUS occurs, so we will always generate the keypress for the modifier.

Yes, my patch also generates key release events for modifiers despite
the fact, that all modifier have been released after the xserver looses
the window focus. When writing the patch, I wasn't sure if this is
always the case, so I made the code a little bit more "robust" in the
sense that it tries to correct the modifier keys in any case (so it will
always work, even if something goes wrong in other code locations).

Best regards,
Oliver

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/