OK, I understand. Thanks! On Sun, 10 May 2020 at 00:05, Mike Jumper <[email protected]> wrote:
> 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 >
