From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30673 invoked by alias); 12 Jan 2012 12:19:54 -0000 Received: (qmail 30648 invoked by uid 22791); 12 Jan 2012 12:19:46 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.22) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Thu, 12 Jan 2012 12:19:20 +0000 Received: (qmail invoked by alias); 12 Jan 2012 12:19:18 -0000 Received: from bastian.ppi.de (EHLO [192.168.103.48]) [194.180.18.1] by mail.gmx.net (mp060) with SMTP; 12 Jan 2012 13:19:18 +0100 Message-ID: <4F0ECFC5.7090903@gmx.de> Date: Thu, 12 Jan 2012 12:19:00 -0000 From: Oliver Schmidt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: cygwin-xfree Subject: Re: considering modifier keys after gaining focus References: <4E4A8D56.6010704@gmx.de> <4F09B4D4.4070905@gmx.de> <4F0AF463.5050707@dronecode.org.uk> <4F0B2DC8.9030706@gmx.de> <4F0DC3DF.8000802@dronecode.org.uk> In-Reply-To: <4F0DC3DF.8000802@dronecode.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com X-SW-Source: 2012-01/txt/msg00016.txt.bz2 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/