@ sign not at expected spot (german keyboard tested)
- @david
Hi,
I just noticed, that I cannot find a way to get the "@" (at) sign used on a machine that is connected to the TinyPilot. What works:
a.) Pressing directly (no TinyPilot involved) the @at sign on the remote machine (remote: machine where TinyPilot is connected)
b.) Pressing the @at sign on the locale machine (and TinyPilot noticing it. See screenshot). But the @ does not show up in an editor at the remote machine
c.) Pressing the TinyPilot virtual keyboard @ (shift-2) also does not work.
d.) What works is pressing [ALT/Option]-q on the locale machine. This shows << << << (see screenshot).
This show a "@" on the remote machine, where TinyPilot is connected to.
What the "Meta" means in both screenshots, I donno, the key is shown as "Alt" in this "row", but I am tooo slow to get it on a screenshot.
Would be great if this could be fixed. I may have a special setup here (Mac is local, Windows is remote),. so maybe it is a different keypress on a Windows local machine, as I remember Mac and Windows have the "@" on a totally different spot at the keyboard.
thanks
Juergen
David @david2023-05-05 13:07:37.757ZHi Juergen, sorry that you're running into this keyboard issue.
This sounds like an issue between different keyboard layouts. Like you mentioned, Mac and Windows have
@in a different spot (we have the same issue with UK layouts between Mac and Windows).When typing
@on your (Windows) target machine, you need to use the keys for the Windows layout - rather than the@key on your local machine.I confirmed that typing Right
Option+qon my Mac results in@on my target machine with a German keyboard layout. TinyPilot displays the keys based on the keyboard layout of your client machine. Because of my Mac's keyboard layout, the TinyPilot web interface displaysAlt+æcompared to yourMeta+«.In this case, Right
Option+qis equivalent to typingAltGr+qon a Windows German layout.What the "Meta" means in both screenshots, I donno,
The Meta key is a name given to modifier keys like the
Windowskey and a Mac'sCommandkey. It's possible that other keys have this label too.I hope that clarifies this behavior. Please let me know if you have any other questions.
In reply tofft⬆:@fft2023-05-05 13:10:49.957ZHi David,
I would expect that the virtual keyboard of TinyPilot always puts in the correct char, which it does not (at least in this case with the @).
thanks
Juergen
David @david2023-05-05 14:15:29.550ZWith the TinyPilot virtual keyboard can you try right
Alt+q? That combination seems to work on for me in this situation.- In reply tofft⬆:David @david2023-05-10 18:34:31.654Z
Hi Juergen, I think I may have misinterpreted your follow-up question - hopefully I can answer it better this time around.
TinyPilot's virtual keyboard uses the ANSI US layout, which is why we have to use right
Alt+qin this particular situation. Unfortunately, it's not yet possible to translate key input from the local keyboard to the target computer (e.g.@mapping to@regardless of keyboard layout). One potential way of solving this would be to have the user specify the target computer's keyboard layout, and then translating the key input from there. I've created a new GitHub issue to suggest this kind of translation functionality.TinyPilot's key history is based on the client computer's keyboard layout, which is why we see the differing characters in the history even though the resulting key is correct on the target machine (displaying
Meta+«for@in this case).I hope this has better answered your question. Please let me know if you have any other questions.
- In reply tofft⬆:@fft2023-05-11 06:33:17.527Z
Hi David,
thanks for coming back. I think that a "really simply" chracter translation would work in most cases. Reason: TinyPilot works wonderful if keyboards are the same on both ends, which IMHO is a 90% case. I am "special", as I have a Mac lokal, and a Windows remote. I am not sure, but I think there are only a few chars, that need to be translated. Apple for whatever reasons decided to put the @ in the "option-L" and windows has it in "Altgr-q" (which is really hard if you switch from Windows to Mac, as in the first few weeks, you close all your E-Mails as altgr-Q in mac closes a window :-) So for this "hardware keyboard to hardware keyboard" case, I think only a few chars need to be translated, and even TinyPilot might be able to support a translation table the user can choose.
I than hoped that the virtual keyboard would solve my problem, but I now understand, that this seems to be the bigger issue. Would be nice for all Europeans, but if not done correct, you might have a "pass in the wasp net" as this is like fixing the old keyboard problems from computer stoneage :-) So my idea would be to have a translation "somehow" between the keys that are "queued" and "what is send" to the remote machine. (even after the virtual key is pressed).
I personally assume a relatively small table might solve 99.5% of the problems if the table can be adapted by the user to his specific needs.thanks
Juergen- David @david2023-05-11 11:11:06.336Z
No problem! Yeah I agree that we could cover a lot of cases by covering Windows and Mac differences on European layouts. I have exactly the same experience when I use my Mac, so I know that it can get frustrating.
@fft2023-06-01 16:07:37.952ZHi David.
The issue makes more problems, when you want to login on a remote machine, and cannot do so, because in your password is a char, that is mapped differently. Problem than is, that you do not even see what happens, as passwords are hidden. You only get "wrong password", and have basically little chance to find out why.
So definitely an issue for us Europeans :-) ...thanks
Juergen- David @david2023-06-02 00:27:33.783Z
I can definitely empathize with you on that one, Juergen. I've almost definitely entered a password only for it to fail because of differing keyboard layouts between the client and target machines.
Just to clarify, this isn't stopping you from logging in is it? You can still log in if you use different input keys for the password?
One workaround for now might be to install a third-party Mac keyboard on your Windows machine (I found this one on GitHub, but I can't vouch for it since I haven't tried it).
- @fft2023-06-02 03:42:08.879Z
Hi David. Yes, it was the same situation. You type a key, and on the remote it was different. Problem is, you only get „wrong password“ and as you do not see, that they key is changed, it is really hard to get an idea what is wrong. If you get the idea, and have the chance to work around, than you can login. Problem with passwords is, that they sometimes have wild chars, wich I even do not know how to produce on my local keyboard (I have a keyboard manager and copy paste). In this specific case we hat to change the password, to work around.
thanks Jürgen- David @david2023-06-05 00:17:11.469Z
Ahh I see - I'm glad this issue isn't stopping you from logging in. Non-alpha-numeric characters are the main issue here. It's likely not that useful to you since you use a password manager and copy/paste, but another workaround is to use the target machine's on-screen keyboard to enter characters.