Handle accents

[fabmars]

When typying é on a french keyboard (2 being on the same key using shift)

• expected: capture "é"
• actual: capturing "2"
  The same will happen with all accents and with other keyboards and accented languages too.

[fabmars]

Maybe work on a "transliterated" version of the forbidden phrases and inputs, but it may have a performance cost. Maybe add a config switch for it.

2 options, the first one WILL do the job, not sure about the second:

• http://site.icu-project.org/home
• https://docs.oracle.com/javase/8/docs/api/java/text/Normalizer.html

[fabmars]

@Draluy please assign this one to me.

[fabmars]

Actually bound to
kwhat/jnativehook#170
whose dupes are ~
kwhat/jnativehook#183
kwhat/jnativehook#184
kwhat/jnativehook#213

[Draluy]

Tried with version 2.0.3 and no luck either. 2.1.1 may be better in that regard from what I read? Maybe worth a shot to compile it and test.

[fabmars]

Hmm fantastic, the builds from https://oss.sonatype.org/content/repositories/snapshots/com/1stleg/jnativehook/2.1.SNAPSHOT/ cannot be downloaded for some reason.

So I went ahead and compiled the thing using the wiki. Which of course wasn't straightfoward for Windows. You need to do 2 extra things:

1. Add the env MSYS2_PATH_TYPE=inherit to benefit from the Win Path.
   Compiling Error kwhat/jnativehook#105
   https://sourceforge.net/p/msys2/discussion/general/thread/dbe17030/

2. Run it from Mingw, NOT Msys2
   Jnativehook build error kwhat/jnativehook#161

And bloody install the file in .m2 of course
mvn install:install-file -Dfile=D:/dev/workspace/jnativehook/jar/jnativehook-2.1.20200112.jar -DgroupId=com.1stleg -DartifactId=jnativehook -Dversion=2.1.1-SNAPSHOT -Dpackaging=jar

Bottomline:

Jan 12, 2020 4:01:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_key_pressed [227]: Key 0X21 pressed. (0X46)

Jan 12, 2020 4:01:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: keycode_to_unicode [710]: Using keyboard layout 0X00000000040C0409.

Jan 12, 2020 4:01:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_key_pressed [252]: Key 0 typed. (f)

Jan 12, 2020 4:01:20 PM org.jnativehook.GlobalScreen$NativeHookThread enable
INFO: process_key_released [286]: Key 0X21 released. (0X46)

...and our listener is never fired !!!

Might be linked to kwhat/jnativehook#226, or kwhat/jnativehook#263 although jnativehook does find my keyb map.

Giving up for now. I'll build it on Linux and see if there's any improvement...

[fabmars]

Leaned on it again and found the issue very quickly thanks to the NativeHookDemo provided within the jnativehook doc: there, an alternate event executor is set up.
https://github.com/kwhat/jnativehook/blob/2.1/src/java/org/jnativehook/example/NativeHookDemo.java and listeners are fired as they should be.

I checked the jnativehook source code and saw that one executor is supposed to be instantiated by default https://github.com/kwhat/jnativehook/blob/2.1/src/java/org/jnativehook/GlobalScreen.java#L669

And just below is also written that no listener would be called if no executor service was registered: https://github.com/kwhat/jnativehook/blob/2.1/src/java/org/jnativehook/GlobalScreen.java#L674

Which is exactly what's happening since DefaultDispatchService isn't instanciated by default anymore.
https://github.com/kwhat/jnativehook/blob/2.1/src/java/org/jnativehook/GlobalScreen.java#L416

The change in the source code happened on 2017-07-30, commit 32fcd1f1ff760d1d22355a33ed07b22897954b03

At first I didn't want to believe it, but fact is, the latest jnativehook build is from 2017-01-25
as both the jar and mvnrepository tell: https://mvnrepository.com/artifact/com.1stleg/jnativehook/2.1.0

Quick fix for us:

            GlobalScreen.registerNativeHook();
            GlobalScreen.setEventDispatcher(new DefaultDispatchService());
            GlobalScreen.addNativeKeyListener(...);

And I'm opening a new issue on jnativehook: kwhat/jnativehook#277

[Draluy]

Awesome job investigating that!
Cheers,

[fabmars]

Fun fact: did you know that the "croissant" emoji 🥐 is 0x1F950, and that it's actually impossible to type it on Windows: keeping Alt pressed + F triggers the "File" menu.

And still no chocolate bread emoji in 2020. Just this: 🥐🍫, although those exist: 🍪🍩🥞. SHAME!

[Draluy]

I vote for banning them anyway, as they can be used as a workaround, and its a cheap fix. Also, with millenials using emojis as words...

[fabmars]

Right #14

[kwhat]

This should be resolved in 2.2. Has this been tested with 2.2.1?

[fabmars]

This should be resolved in 2.2. Has this been tested with 2.2.1?

Hi Alex @kwhat , David is sick with the Covid right now, so I'll answer: we had a working build with a 2.2-SNAPSHOT, so yeah I bet this should work with a stable one. But I will check to be extra sure. Thanks a lot.
Have a pleasant week-end.

[fabmars]

Yeah it works all right with JNativeHook 2.2.1
Thanks @kwhat !!