Wed 11 Feb 2009 10:34:40 AM UTC, comment #9:
if no objections arise, I will soon commit the proposed change.
|
Tue 10 Feb 2009 09:28:57 AM UTC, comment #8:
Just to make it clear. Riccardo is suggesting to ignore any AltGr+LeftControl (and RightALt+LeftControl) combination and treat that as Alt.
|
Tue 10 Feb 2009 12:08:34 AM UTC, comment #7:
I think I found a good compromise:
at line 1667 of WIN32Server.m
/* AltGr is mapped to right alt + left control */
if ((keyState[VK_CONTROL] & 128) && !((keyState[VK_LCONTROL] & 128) && (keySta
te[VK_RMENU] & 128)))
eventFlags |= NSControlKeyMask;
this works and it robs just one of the possible 4 alt-ctrl combinations, the correct one for my keyboard (strangely, altgr, which is at right, couples with the left control). You can still use the remaining if needed. "works for me"
[the discovered fact that left-alt + key doesn't even seem to give an event is even stranger... and still remains)
|
Mon 09 Feb 2009 10:26:13 PM UTC, comment #6:
the trick doesn't appear to work... if VK_CONTROL is set either RCOTNROL or LCONTROL are set too... I found this comment around:
// 2. Some keyboard layouts use the Right-ALT key as a 2nd level
// shift key, and label it as AltGr. With these layouts, it is IMPOSSIBLE
// to distinguish between "Ctrl + AltGr + Key" and "AltGr + Key" during the
// WM_KEYDOWN messages. Neither the keyboard state nor the messages differ
// between the two key sequences.
//
// Implications: suppose some menu command has been bound to "Ctrl + }". On my
// Swiss keyboard, I have to type "AltGr + $" to get the right bracket. This means
// that FOX receives the sames messages if I type "}" or "Left-Ctrl + }" !
//
// Solution: I wrote a function winkeyCheckLayout() that checks if a keyboard
// layout uses the Right-Alt key as AltGr. If it does, I interpret any combination
// of "Left-Ctrl + AltGr" as "AltGr", i.e. I drop the Left-Ctrl key. Keyboard
// accelerators can still be reached with the "Right-Ctrl".
//
//
// 3. Related to the previous comment: how can we distinguish between left
// and right Alt / Ctrl / Shift ? Windows 95/98/Me do not set the
// corresponding VK_L/VK_R keyboard states, as NT does. We must look
// at bit 24, the "extended bit" of lParam in the window messages. The code
// below goes to great lenghts to correctly determine the state of the
// left / right keys on these systems.
it is the only place where you read this. Most places say that on keyboard without AltGr you can use Alt+Ctrl to emulate it... this doesn't mean of course that AltGr gets mapped precisely taht way though
|
Mon 02 Feb 2009 10:00:36 PM UTC, comment #5:
Sorry, I forgot that I cannot test it on that virtual machine, an Apple keyboard just doesn't have an AltGr key :-(
As soon as compilation on Windows works again for me, I will hack that code in and somebody else needs to test it.
|
Thu 29 Jan 2009 09:46:55 AM UTC, comment #4:
This second approach sounds like a nice solution. I will try it on my virtual machine as soon as I find time to fire up Windows.
|
Wed 28 Jan 2009 09:47:36 PM UTC, comment #3:
Since AltGr is not part of the OpenStep/Cocoa API, I see two possible options here:
1) Just ignore that AltGr key is pressed
2) Set NSAlternateKeyMask
I'm not really sure about what is the better approach here. It looks like Apple and NeXT did follow the latter approach (however, having no running OpenStep or Rhapsody for Windows at hand, I cannot really prove this, it is just what I read from the OpenStep documentation and Apple's older AppKit release notes).
However, setting NSControlKeyMask definitely looks wrong to me. After googling for VK_CONTROL a bit, it seems that Windows does indeed send that modifier (for whatever reason). Maybe setting NSControlKeyMask only when VK_LCONTROL or VK_RCONTROL is set is an option.
|
Wed 28 Jan 2009 08:38:30 AM UTC, comment #2:
Could you please explain once more what you are suggesting?
Should we just set the NSAlternateKeyMask on Windows when we get an AltGr key? (Treating AltGr as Alt-R) Aren't we loosing informations about modifiers that way?
Another problem with that approach is that, as far as I remember, it is already Windows that tells us that VK_CONTROL is set, when AltGr is pressed. We'll need to find a way to undo this.
BTW: Cmd-@ and Cmd-Alt-2 are the same on Swiss keyboards, on German ones @ is AltGr-q.
|
Sun 25 Jan 2009 07:06:33 PM UTC, comment #1:
The Windows backend certainly should not use NSControlKeyMask here, but only NSAlternateKeyMask. In fact, this is what happens on Apple systems (which do not have a separate AltGr key anyway). However, beware that this will create problems with applications like Terminal.app or Emacs.app, which assume that the Alternate key can be used as an independent modifier key besides the Command key. In addition, as you've already noted, the gui must be more careful when checking keyboard equivalents so that, e.g., both keyboard equivalents Cmd-@ and Cmd-Alt-2 are recognized, which are physically the same key combination on a German PC keyboard. In principle, the same should apply to the dictionaries used by NSInputManager.
|
Sat 24 Jan 2009 01:58:17 PM UTC, original submission:
The X backend handles the AltGr key by changing the characters, but not setting any modifiers. In the MS Windows backend we also set the NSControlKeyMask and NSAlternateKeyMask modifiers. This results in keys like @, that are on German keyboards only available by pressing AltGr, generating a beep, as NSInputManager get the control modifier and does not know how to handle that.
I think that the MS Windows backend is more correct here, the modifiers were pressed and we should report them, but then gui should be able to deal with that case, before we change the X backend to do the same.
|