On Sat, May 9, 2020, 12:36 gabriel sztejnworcel <[email protected]>
wrote:

> Thanks for you answer Mike!
>
> What if the server has 2 layouts, for example French (azerty) and Hebrew,
> and the user wants to switch between them during the session? Won't that be
> a problem?
>

Yes. The user should switch layouts on the client side, not within the
server.

If the client can send the key scancodes, won't that solve the problem in
> this scenario?


It would shift the location of layout switching to the server. Doing so
would make things behave the way you specifically want, but may be a step
backwards from the goal of making things as seamless as possible.

Is it technically possible to implement this?


With recent changes to JavaScript key events, possibly, but not across the
board. Not all input devices have scancodes.

The biggest concerns here would be:

1) Loss of seamlessness. Keyboard behavior *should* be dictated by the
behavior of the client's keyboard.

2) Loss of compatibility. Not all platforms will have scancodes, let alone
ones that correspond to Windows.

3) Loss of functionality. Not all keys produce key events, and some keys do
so only unreliably.

It may be reasonable to provide the option at the connection level, to
allow the administrator to choose whether to favor the client-side layout
(and translate to a known server layout) or the server-side layout (and
entirely ignore client-side key identity).

Philosophically, I don't like it. If such a change is implemented, I would
be concerned that it might be used as a crutch on the admin side (to avoid
having to think about what layout is selected), to the detriment of users.

It is something that may be necessary in the case that keyboard layout MUST
be changeable within the remote desktop. Direct connections to VM consoles
come to mind.

Even if implemented, I don't think that is the solution you should look
toward. It would be better to allow your users to transparently use their
keyboard as it is locally configured, without having them worry about
manually configuring things again within the remote desktop. This is the
way things are already designed.

- Mike

Reply via email to