Bug 5272

Summary: Impossible to use non-Roman keyboard layout on macOS
Product: ThinLinc Reporter: Peter Åstrand <astrand>
Component: VNCAssignee: Pierre Ossman <ossman>
Status: CLOSED FIXED    
Severity: Normal CC: adaha, samuel
Priority: P2 Keywords: adaha_tester, relnotes, upstream
Version: 4.2.0   
Target Milestone: 4.19.0   
Hardware: PC   
OS: Unknown   
See Also: https://bugzilla.cendio.com/show_bug.cgi?id=5932
https://bugzilla.cendio.com/show_bug.cgi?id=8522
https://bugzilla.cendio.com/show_bug.cgi?id=8523
Acceptance Criteria:
MUST: * All common, non-input method, keyboard layouts should work in ThinLinc * Common input method layouts should automatically switch to a non-input method layout in ThinLinc SHOULD: * All non-input method keyboard layouts should work in ThinLinc * All input method layouts should automatically switch to a non-input method layout in ThinLinc
Bug Depends on: 8502    
Bug Blocks: 3523    
Attachments: patch for FLTK

Description Peter Åstrand cendio 2014-09-25 13:00:00 CEST 
On Mac OS X, the Russian keyboard layout is apparently implemented as, or requires, input methods. Since our current approach is to let input method handling be done on the server side, we are disabling input methods in vncviewer. When this happens, the keyboard layout changes to someelse else(!) 

The same effect can also be seen in Firefox or Safari, when switching to a password input field. This is somewhat surprising. 

I've verified this on both 10.4 and 10.9, so this is not something new. Note however that 10.4 has a more advanced control panel UI, which describes layout type. The Swedish layout is described as "Keyboard/Roman", while the Russian layout is "Keyboard/Cyrillic". Katakana is a subtype of "Kotoeri", of type "Input method/Japanese". 

My conclusion is that the problem is not that the Russian layout requires "Input methods", but rather that it is of a non-Roman type.
Comment 1 Peter Åstrand cendio 2014-09-25 13:06:33 CEST 
Apparently, non-latin passwords are not allowed on Mac OS X. Other person with same problem:

https://discussions.apple.com/thread/2679736?tstart=0
Comment 2 Peter Åstrand cendio 2014-09-29 11:06:39 CEST 
It turns out that this is a problem for other layouts as well, for example Greek. The Greek alphabet is a parent for the Latin/Roman alphabet, so it is perhaps not a surprise that a Greek layout is not accepted on OS X, since we are apparently restricting ourselves to Roman layouts.
Comment 4 Pierre Ossman cendio 2019-04-04 10:59:48 CEST 
Apple has apparently decided to hide the internal details of keyboard handling. Fortunately the internet never forgets:

https://web.archive.org/web/20140604054226/https://developer.apple.com/library/Mac/documentation/TextFonts/Reference/TextInputSourcesReference/Reference/reference.html
Comment 5 Pierre Ossman cendio 2019-04-04 11:37:10 CEST 
Created attachment 906 [details]
patch for FLTK

I was looking at the macOS keyboard input for an upstream issue, and I think I stumbled upon a way to solve this.

The attached patch seems to disable the stuff we don't want, and keep the things we do.

Instead of filtering out only "ASCII" input sources, we instead we focus on those that claim to be of the basic "Layout" type. This should exclude various forms of input methods.

Needs more testing, but it seems promising.

(this method also seems to match the system settings, which refuses to let you remove the last "normal" input source)
Comment 6 Pierre Ossman cendio 2021-12-14 09:08:42 CET 
(In reply to Pierre Ossman from comment #5)
> (this method also seems to match the system settings, which refuses to let
> you remove the last "normal" input source)

This seems to have changed. I couldn't configure macOS 12 to only have Russian layout.
Comment 9 Pierre Ossman cendio 2025-02-18 12:50:47 CET 
Interesting layouts to test:

 * Greek
 * Various cyrillic[1]
 * Arabic
 * Georgian
 * Hebrew
 * Urdu
 * Various Bengali[2] or InScript[3] (might just be input methods)
 * Dzongkha
 * Khmer
 * Sinhala
 * Tamil

[1] https://en.wikipedia.org/wiki/JCUKEN
[2] https://en.wikipedia.org/wiki/Bengali_input_methods
[3] https://en.wikipedia.org/wiki/InScript_keyboard
Comment 10 Pierre Ossman cendio 2025-02-18 14:35:32 CET 
Found one issue already; switching from an overly restrictive application (e.g. an older ThinLinc, or a password field in Safari) doesn't properly re-enable things. You have to land in another application first.

E.g.

1. Enable Russian
2. Open a password field in Safari
3. Switch focus to ThinLinc

The layout is now stuck in the Roman layout that Safari set.

Whilst this works:

1. Enable Russian
2. Open a password field in Safari
3. Switch focus to Finder
4. Switch focus to ThinLinc

You now have working Russian layout in ThinLinc.
Comment 11 Pierre Ossman cendio 2025-02-18 14:46:29 CET 
Another thing to note is that old ThinLinc client and Safari (password fields) manage to gray out unsupported layouts in the keyboard layout menu. For the new client, nothing is grayed out. Not even the ones that should be blocked.

As a result, you can pick things like Japanese, even though it should be blocked. It even manages to send sensible keysyms.

Once you switch focus and back, things get properly reset, though.
Comment 12 Pierre Ossman cendio 2025-02-19 12:42:27 CET 
Apparently that isn't entirely reliable in the old client. It works somewhat randomly.
Comment 13 Pierre Ossman cendio 2025-02-19 13:14:10 CET 
Reported the issue of re-enabling things upstream, as it can be seen in FLTKs demo applications:

https://github.com/fltk/fltk/issues/1208
Comment 15 Pierre Ossman cendio 2025-02-20 11:37:19 CET 
Seems to be working well in most cases now. Some more obscure layouts are hitting other bugs, though:

 * Complex dead keys (bug 5932)
 * Non-BMP symbols (bug 8522)
 * Decomposed Unicode symbols (bug 8523)

Hopefully, these are extremely rarely used with ThinLinc.
Comment 17 Pierre Ossman cendio 2025-02-20 17:03:43 CET 
Testing was mostly done on macOS, since almost all code changes was in macOS specific code. I did a quick test on Linux and Windows as well, though.

> MUST:
> 
>  * All common, non-input method, keyboard layouts should work in ThinLinc

I'd say so. Could not find any issues in what I'd consider common layouts. Hebrew doesn't fully work, which is the only gray area.

>  * Common input method layouts should automatically switch to a non-input method layout in ThinLinc

Yes, works well. Tested with Japanese layout. Also tested it on Linux and Windows.

> SHOULD:
> 
>  * All non-input method keyboard layouts should work in ThinLinc

No. Some layouts, as listed above, still suffer from other issues.

>  * All input method layouts should automatically switch to a non-input method layout in ThinLinc

I think so. I tested just a few, though. Didn't seem worthwhile to test everything as we have nothing indicating there are issues.
Comment 18 Adam Halim cendio 2025-02-27 12:20:15 CET 
Tested client build 3821 on Windows 10, macOS 15, Fedora 41, and server build
3390 on RHEL 9.

Tested some non-input keyboard layouts, such as Russian and Japanese. Did not
see any issues on any platform.

I tested some input method layouts (Chinese, Japanese, Korean) and can confirm
that the client automatically switches to a non-input method.

> MUST:
>  * All common, non-input method, keyboard layouts should work in ThinLinc
I did not try all the available languages on the platforms I tested on, but I
couldn't find any issues with the ones tested.
>  * Common input method layouts should automatically switch to a non-input method 
>    layout in ThinLinc
From what I can tell, this seems to work as expected.
> SHOULD:
>  * All non-input method keyboard layouts should work in ThinLinc
As mentioned previously, there are some layouts (e.g. Hebrew) that don't work.
>  * All input method layouts should automatically switch to a non-input method 
>    layout in ThinLinc
This worked as expected with the layouts I tested.

Closing.