Issues on accents through Java Viewer

[Rafael Guimaraes]

Hi DRC,

I have been facing an issue when using accents through the Java Viewer (JWS) on a Windows computer. It behaves differently from what I get when using a Linux client machine...

The problem lies on the following accents: ` and ^. At least in the brazilian keyboard (yeap, I am brazilian :)), these accents are generated by a combination of Shift and another key.

Shift + ~ = ^

Shift + ' = `

The curious thing about it is the keypress and keyrelease events seems to be correctly sent to the remote session by the Java WebStart Client, however, when using Linux, when shift is kept pressed, it modifies the subsequent character. The same doesn't happen when using Windows.

Let me show you some snapshots of the same session being accessed through the Java WebStart Client (version 2.2) on both a Linux client and a Windows client.

Linux (pressing and releasing the ~ key):

Linux (pressing Shift, pressing and releasing the ~ key and releasing Shift):

Windows (pressing and releasing the ~ key):

Windows (pressing Shift, pressing and releasing the ~ key and releasing Shift):

The same happens with the combination of Shift + ' = `.

Any suggestions on how to solve this?

Thanks in advance!

Best regards,

Rafael Guimarães

[DRC]

I’ll investigate and see if I can work around the issue. Fixing keyboard issues like that has mostly been a game of “Whack-a-Mole.” The better long-term solution will be implementing the QEMU RFB extension that allows the viewer to send key codes rather than keysyms.

On Jan 3, 2019, at 8:15 AM, Rafael Guimaraes <rgu...@gmail.com> wrote:

Hi DRC,

I have been facing an issue when using accents through the Java Viewer (JWS) on a Windows computer. It behaves differently from what I get when using a Linux client machine...

The problem lies on the following accents: ` and ^. At least in the brazilian keyboard (yeap, I am brazilian :)), these accents are generated by a combination of Shift and another key.

Shift + ~ = ^

Shift + ' = `

The curious thing about it is the keypress and keyrelease events seems to be correctly sent to the remote session by the Java WebStart Client, however, when using Linux, when shift is kept pressed, it modifies the subsequent character. The same doesn't happen when using Windows.

Let me show you some snapshots of the same session being accessed through the Java WebStart Client (version 2.2) on both a Linux client and a Windows client.

Linux (pressing and releasing the ~ key):

<image.png>

Linux (pressing Shift, pressing and releasing the ~ key and releasing Shift):

<image.png>

Windows (pressing and releasing the ~ key):

<image.png>

Windows (pressing Shift, pressing and releasing the ~ key and releasing Shift):

<image.png>

The same happens with the combination of Shift + ' = `.

Any suggestions on how to solve this?

Thanks in advance!

Best regards,

Rafael Guimarães

--
You received this message because you are subscribed to the Google Groups "TurboVNC Developer Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-devel/CAMCG4_-rv_ggmJBMH-1zt55HyC%3DKtRZX2R8b50DRsfWU-nAxRQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[DRC]

Sorry for the delay in responding to this.  I have reproduced the problem.  The proximate cause is unfortunately a Java issue.  It appears that, in both cases, Java is producing an identical KeyEvent regardless of whether Shift is pressed in conjunction with the dead tilde or dead grave accent key.  Since the unextended RFB protocol uses key symbols rather than key codes for key events, it is necessary for the TurboVNC Viewer to translate raw key events from Java (or from Win32, in the case of the native TurboVNC Viewer) into key symbols, and this relies on Java or Windows to generate correct key symbols for a particular keyboard layout and modifier combination.  Unfortunately, that doesn't always happen.  The long-term solution for this will be to implement

https://github.com/TurboVNC/turbovnc/issues/108

which will remove the need for the TurboVNC Viewer to translate keycodes into keysyms and thus remove any dependence on the client-side keyboard layout (as well as any reliance upon Java or Win32 to do the "right thing" with regard to key events.)  Note that that feature is in need of funding.

[DRC]

The dev/3.1 evolving builds should now have a proper fix for all dead key and other international key mapping issues.  (Key mapping is now done on the server side rather than the client side.)

DRC

On 1/3/19 7:15 AM, Rafael Guimaraes wrote: