public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: Oliver Schmidt <oschmidt-mailinglists@gmx.de>
To: cygwin-xfree <cygwin-xfree@cygwin.com>
Subject: Re: considering modifier keys after gaining focus
Date: Mon, 09 Jan 2012 18:11:00 -0000	[thread overview]
Message-ID: <4F0B2DC8.9030706@gmx.de> (raw)
In-Reply-To: <4F0AF463.5050707@dronecode.org.uk>

Hi Jon,

On 09.01.2012 15:06, Jon TURNEY wrote:
> I have a few questions and comments below:
> 
>> Example: in window A Ctrl + some key opens a window B, then in window B
>> Ctrl + some other key triggers the next action. However after the opening
>> of window B the Ctrl key has to be released and pressed again. If the user
>> keeps the Ctrl key holding when the window B is opened, the next key press
>> X will be interpreted as X and not as Ctrl+X.
> 
> Can you give an example of an application where this causes a problem, so I
> can test your patch?

because current cygwin x-server is not able to raise windows, you could
only test the case, that a new window is created. Any X11 program that
can create windows and has keyboard shortcuts will do it, e.g. take
NEdit, press Ctrl+N for a new window, hold the Ctrl key and press S
(i.e. Ctrl+S) for saving.

> The code would seem to end up simpler (which is an important consideration) if
> we were to modify winKeybdReleaseKeys() not to release modifier keys.  Some
> archaeology is probably required to determine if releasing the modifier keys
> in winKeybdReleaseKeys() is necessary to avoid some other undesirable behaviour?

I don't know anything about the cygwin X server history, I can only
guess why the current code is as it is: Perhaps the modifier keys are
released afer loosing a window's focus because if another Non-cygwin
window gains the focus, no more modifier change events will arrive to
the cygwin x server.

> This also begs the question why is it only necessary to press some some subset
> of the down keys on WM_SETFOCUS?  Does the X server behave correctly if a
> non-modifier key is held down while focus moves from one X server window to
> another, or from one X server window to a  native window an back?

My code simply updates the xserver's internal state about the modifier
keys after gaining the window focus. Other keys behave correctly,
because the xserver doesn't have an internal state for them.

> Why is is correct to use GetAsyncKeyState() here and not GetKeyState()?  If we
> use GetAsyncKeyState() there may be a message pending (See the remarks on
> GetKeyState() in MSDN) to change to the key state, so we might conceivably
> double the key press?

I will try using GetKeyState tomorrow. I just wanted to be sure to get
the current key state when the window gets the focus.

> This maps VK_CONTROL to KEY_LCtrl.  Why not use VK_LCONTROL and VK_RCONTROL,
> so the generated key-press is for the correct key?
> Ditto for VK_LSHIFT and VK_RSHIFT

Perhaps this might improve the patch, however the internal modifier
state of the xserver has only ShiftMask, LockMask, ControlMask,
Mod1Mask, Mod2Mask, Mod3Mask, Mod4Mask, and Mod5Mask. So the internal
state does not distinguish betweem left or right shift key.

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/


  reply	other threads:[~2012-01-09 18:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-16 15:31 Oliver Schmidt
2011-08-21  8:44 ` Corinna Vinschen
2011-08-21 10:04   ` Oliver Schmidt
2012-01-08 15:23 ` Oliver Schmidt
2012-01-09 14:06   ` Jon TURNEY
2012-01-09 18:11     ` Oliver Schmidt [this message]
2012-01-10  9:47       ` Oliver Schmidt
2012-01-10 10:15         ` Oliver Schmidt
2012-01-11 17:16       ` Jon TURNEY
2012-01-12 12:19         ` Oliver Schmidt
2012-01-12 12:38           ` Oliver Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F0B2DC8.9030706@gmx.de \
    --to=oschmidt-mailinglists@gmx.de \
    --cc=cygwin-xfree@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).