Update of bug #25397 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #9, bug #25397 (project gnustep):
if no objections arise, I will soon commit the proposed change.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25397
___
Follow-up Comment #8, bug #25397 (project gnustep):
Just to make it clear. Riccardo is suggesting to ignore any AltGr+LeftControl
(and RightALt+LeftControl) combination and treat that as Alt.
___
Reply to this item at:
Follow-up Comment #7, bug #25397 (project gnustep):
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 |=
Follow-up Comment #5, bug #25397 (project gnustep):
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.
Follow-up Comment #2, bug #25397 (project gnustep):
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
Follow-up Comment #3, bug #25397 (project gnustep):
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-up Comment #1, bug #25397 (project gnustep):
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
