I would not recommend internal APIs, unless someone wants to build
JavaFX to help diagnose it.
In any case it sounds like Johan has discovered a bug -- at least on
Windows -- in the key handler for dead keys. We should test this on
macOS and Linux as well.
-- Kevin
On 9/25/2024 8:14 AM, Thiago Milczarek Sayão wrote:
Johan,
It's an internal API, but we can use it for testing purposes (I'm not
sure if there's a public API for that).
SceneHelper.enableInputMethodEvents(scene, false);
IME is used for entering complex characters in some languages such as
Chinese, Korean, Japanese, etc.
On Linux, setting the keyboard to en_US will also add the extra space,
except if I choose the en_US with dead keys variation.
If you try it on notepad, is it the same behaviour? If not, I think it
might be a bug.
-- Thiago.
Em qua., 25 de set. de 2024 às 11:12, Johan Corveleyn
<jcor...@gmail.com> escreveu:
Hi Thiago,
Thank you for your answer. I am experiencing this issue on Windows
(Windows 10 and 11).
Now, it dawns on me that:
- I have a QWERTY keyboard (standard US layout).
- I have my keyboard layout setting in Windows configured to "US
International". That way the keys for ~, ^, ', " become "dead keys"
(waiting for next keystroke).
- If I change my keyboard layout setting to "US" then I can't
reproduce anymore because those keystrokes no longer act like dead
keys (~, ^, ... immediately give that character).
I don't know how this is handled on Linux or Mac. Do they also have
something like a "US International" keyboard layout setting so ^
becomes a dead key? Or does it work differently if I want to type â or
ë, or a standalone ^?
I'm not sure what you mean by disabling IME or how to know that it's
enabled. Can I enable/disable this programmatically in JavaFX? Or is
this an OS keyboard layout setting (anyway: just having a standard "US
input" makes this non reproducible because I can no longer type dead
keys)?
If you have a keyboard input with dead keys it's super easy to test
this with a simple program like:
[[[
public class DeadKeysFX extends Application {
@Override
public void start(Stage stage) {
TextField textField = new TextField();
Scene scene = new Scene(textField);
stage.setScene(scene);
stage.show();
}
}
]]]
Just type ^+<space> and see whether you get one or two characters. In
all non-JavaFX programs (including Java Swing) I get a single '^'. In
JavaFX I get a '^ '.
--
Johan
On Tue, Sep 24, 2024 at 5:16 PM Thiago Milczarek Sayão
<thiago.sa...@gmail.com> wrote:
>
> Hi Johan,
>
> It might vary be platform. Which one are you using? (Windows,
Mac, Linux).
>
> Try disabling IME (Input Method Editor) and see it it works.
>
> - Thiago
>
> Em ter., 24 de set. de 2024 11:51, Johan Corveleyn
<jcor...@gmail.com> escreveu:
>>
>> Hi,
>>
>> (This is my first post here, hope I'm following the right path)
>>
>> It seems JavaFX TextFields (and friends) do not automatically
convert
>> <dead key>+<space> into simply <dead key character>. They make
it into
>> <dead key character>+<space>, which is very atypical. I would
consider
>> this behavior a bug, since it is different from any editor I
know (and
>> makes it very hard to enter a dead key character on its own).
We ran
>> into this with Java 8, I also reproduced it with openjdk 21 +
openjfx
>> 23.
>>
>> For instance if in a JavaFX TextField I type a '^' keystroke,
it waits
>> for the next keystroke (which is normal since it's a dead key,
>> possibly followed by a character on which to put the '^'). But if I
>> then type <space> I expect a simple '^' to appear. Instead, in
JavaFX,
>> '^ ' appears. This does not happen in Swing, nor in any editor or
>> shell or ...
>>
>> Background context: a user of our JavaFX application couldn't
>> authenticate with their password (typed in a PasswordField).
After an
>> awful lot of troubleshooting we found that they used a '^' in their
>> password. Of course the user didn't notice that after typing
^+space
>> two dots appeared in the PasswordField. Now that user knows
they have
>> to backspace after typing ^+space ...
>>
>> I suppose inserting a Swing JPasswordField in our JavaFX app would
>> work around this issue, but ... isn't there a better solution?
>> Shouldn't this be regarded as a bug?
>>
>> --
>> Johan
