<AWT Dev> [13] JDK-8218917: KeyEvent.getModifiers() returns inconsistent values for ALT keys

[Sergey Bylokhov]

On 13/03/2019 03:59, Sergey Malenkov wrote:
> I missed the "for ALT keys" in the bug title and thought that
> "KeyEvent.getModifiers() returns inconsistent values" was about
> incompatible behaviour on different platforms. In fact, JDK-8218917
> should be renamed to something like “The right Alt key on Mac should
> behave as Alt and must not break the left Alt key processing”.

But the "right Alt" should behave like a "left alt" already, it should use both flags:
the common alt(ALT_DOWN_MASK) and the altGr(ALT_GRAPH_DOWN_MASK).

So if the client will follow the spec below it should work as before, isn't it?:
https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/event/InputEvent.html#getModifiersEx()

> On Wed, Mar 13, 2019 at 6:57 AM Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>>
>> On 12/03/2019 12:28, Sergey Malenkov wrote:
>>> Hi Sergey,
>>>
>>> 1. macOS uses a regular Alt key as "Alternate Character Key". This is
>>> the reason why JDK Toolkit defines Ctrl+Alt to select a mnemonic,
>>> instead of simple Alt. See
>>> https://sites.google.com/site/malenkov/java/141229
>>
>> Right, but introducing this flag for the "left alt" could cause even more
>> issues, so this flag is set only for the right.
>>
>>> 3. Regression was caused by adding AltGr to key processing on Mac. But
>>> I found more issues with inconsistent key processing on different
>>> platforms. See http://sites.google.com/site/malenkov/java/190312
>>
>> Not sure that CAPS_LOCK is related.
>>
>>>
>>>
>>> On Tue, Mar 12, 2019 at 4:17 AM Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>>
>>>> On 11/03/2019 17:37, Philip Race wrote:
>>>>> The debate is about AltGraph which an ancient MS-DOSism for
>>>>> asking for an ALTernate GRAPHics bitmap font - all pre-dates windows
>>>>> and I am sure has never been applicable to any MacOS.
>>>>
>>>> It also about the "right alt" which is also know as "AltGraph". I guess currently
>>>> it is implemented as "right alt" on Linux/macOS/windows.
>>>>
>>>> BTW on linux it is also named as "Alternative Characters Key":
>>>> https://help.ubuntu.com/community/ComposeKey
>>>>
>>>>> So someone needs to properly explain why we would claim a Mac keyboard
>>>>> is OK to generate a keycode it doesn't have and cause a slew of regressions
>>>>> in the process ...>
>>>>> If Mac doesn't distinguish these two, we should generate the same keycode for both.
>>>>
>>>> The macOS supports "right alt", otherwise it would not be possible to implement it in java:
>>>> https://developer.apple.com/library/archive/technotes/tn2450/_index.html
>>>>
>>>>
>>>>> One could suppose there is a difference else why two keys, but what is the right
>>>>> thing to do here  that fixes all the problems. What exactly WAS the problem
>>>>> with what was there in the first place ? And if changing it is correct why is it
>>>>> causing regressions ?
>>>>
>>>> Regressions were caused by the bugs in the fix implementation, or am I missed something?
>>>>
>>>>
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>>
>>>>> On 3/12/19, 5:34 AM, Sergey Bylokhov wrote:
>>>>>> Hi, Phil.
>>>>>> On 11/03/2019 07:43, Philip Race wrote:
>>>>>>> The reasoning that AltGraph might be useful to someone is a bit weak
>>>>>>> and I don't think I'd want to support it via system property or build options.
>>>>>>>
>>>>>>> If its not a platform keyboard key, why do we need it ?
>>>>>>
>>>>>> The "AltGraph" key is also commonly referred to as "Right Alt", and
>>>>>> it has been implemented on all platforms as a "Right Alt", it is convenient to
>>>>>> distinguish the left/right alts.
>>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
> 
> 
> 


-- 
Best regards, Sergey.