[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]
From:       Martin Fox <github.com+12087024+beldenfox () openjdk ! java ! net>
Date:       2021-05-25 21:49:05
Message-ID: 7psvBBkKDCQo8VUJPCE3CmreXLyr_d97fy0v-j81TnM=.d1ba2101-11d7-4e46-8175-97e657e2eb25 () github ! com
[Download RAW message or body]

On Tue, 25 May 2021 10:40:50 GMT, Tom Schindl <tschindl@openjdk.org> wrote:

> > Is there some reason you would prefer a Swing-style implementation over the \
> > approach I submitted in this PR? The Swing code breaks down if an accelerator \
> > calls for the Option modifier alone or in addition to Command. I'm still \
> > investigating work-arounds. 
> > (Long story short, Command alters the character we receive in a good way, \
> > providing a low-ASCII character even on non-ASCII layouts like Cyrillic. Option \
> > alters the character in a bad way, often producing an arbitrary symbol. Prior to \
> > macOS 10.15 we can't toss one modifier without tossing the other short of using \
> > UCKeyTranslate.)
> 
> @beldenfox I did not say that the swing version is the way to go and in the end its \
> @kevinrushforth call what route should be taken - I just wanted to show what my \
> initial change would have been without saying it is better than what you are \
> proposing which sounds like is more complete than what swing provides today.

@tomsontom I've added the Swing-style code as WIP PR #519. There are comments in the \
PR that probably should be in the code but I wanted to reduce the code diffs.

PR #519 (and Swing) tend to get codes for punctuation keys wrong on non-US layouts. \
That's not a big issue for accelerator processing since accelerators involving \
punctuation should use KeyCharacterCombinations which work even if the underlying key \
codes are wrong.  (I can't seem to find documentation that tells developers how to \
choose between KeyCodeCombinations and KeyCharacterCombinations. Am I missing \
something?)

There are isolated instances where PR #519 assigns a letter code to a punctuation \
key. For example, on the French keyboard it assigns KeyCode.M to the comma/question \
mark key which is where the M key is on the US layout. This means an app that uses \
both M and one of those punctuation characters as accelerators might see both fire. \
This might be a non-issue, the same problem afflicts the current code and I didn't \
run across any bugs on that.

-------------

PR: https://git.openjdk.java.net/jfx/pull/425


[prev in list] [next in list] [prev in thread] [next in thread]