bugGNUstep - Bugs: bug #25397, Inconsistency in handling Alt Gr...

Group
 
 

bug #25397: Inconsistency in handling Alt Gr key

Submitter:  Fred Kiefer <FredKiefer>
Submitted:  Sat 24 Jan 2009 01:58:17 PM UTC
   
 
Category:  Backend Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 11 Feb 2009 10:34:40 AM UTC, comment #9: 

if no objections arise, I will soon commit the proposed change.

Riccardo Mottola <rmottola>
Group Member
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.

Fred Kiefer <FredKiefer>
Group Member
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)

Riccardo Mottola <rmottola>
Group Member
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

Riccardo Mottola <rmottola>
Group Member
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.

Fred Kiefer <FredKiefer>
Group Member
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.

Fred Kiefer <FredKiefer>
Group Member
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.

Wolfgang Lux <wlux>
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.

Fred Kiefer <FredKiefer>
Group Member
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.

Wolfgang Lux <wlux>
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.

Fred Kiefer <FredKiefer>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by wlux (Posted a comment)
  • -email is unavailable- added by FredKiefer (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-02-13 rmottola Open/ClosedOpen Closed
    2009-02-13 rmottola StatusNone Fixed
    2009-01-29 FredKiefer Assigned toNone FredKiefer
    2009-01-28 FredKiefer Dependencies- bugs #25005 is dependent

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code