-
-
Notifications
You must be signed in to change notification settings - Fork 869
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No support for dvorak (or supposedly others) keyboard layout #451
Comments
Confirming that I can't use Dvorak on macOS -- cool-retro-term disregards my current keyboard layout (switching back and forth the layout setting doesn't affect the terminal). |
Looks like the situation is a bit worse -- I'm on macOS with Dvorak layout turned on: I wonder if it's getting fixed with this PR: #446 (see line 1027 and 1033) |
Is getting the Dvorak keyboard layout just a matter of adding some file here: https://github.com/Swordfish90/qmltermwidget/tree/master/lib/kb-layouts ? |
Unbelievably -- today I launched the app by accident and it is working with Dvorak!!! 🎉 |
Not here. What did you do? |
The app hasn't been updated, so it might be some weird combination of settings. |
Even weirder... I'm using Programmer Dvorak (also on Mac), and I get QWERTY with all the letter keys, but it uses Programmer Dvorak for the number keys. And it can use Hangul (the Korean alphabet) just fine if I switch the layout to Korean. It never did anything like this on Linux. |
I can verify that dvorak is working fine on linux. |
I'm on cool-retro-term version Similarly the So I get neither QWERTY nor DVORAK. The problem goes away and I get full QWERTY when I switch the computer setting to the QWERTY layout, but I can't get Dvorak support 😢 I would love for Dvorak to be supported. Is it straight-forward to add the support? I'm willing to open a PR if someone could point me in the direction of how to fix things. |
What bothers me the most is that a previous version of CRT did support Dvorak, but since I updated to 1.1.1 it forces me to use QWERTY. If an update broke Dvorak, it should be easy enough to undo it, no? I am on an iMac, by the way. Confirmed: version 1.0.1 has full Dvorak support, and 1.1.0 does not. |
Programmer Dvorak works on 1.0.1 too! |
I can confirm that using cool-retro-term 1.1.1 with the Colemak keyboard layout setting (System Preferences > Keyboard > Input Sources > Colemak) on macOS 10.13.6 yields the incorrect behavior described in this issue — QWERTY appears to be used instead. Downgrading to cool-retro-term 1.0.1 restores the correct behavior, with the Colemak layout yielding the correct characters. |
Ditto everything with Colemak 1.0.1 is working 1.1.1 isn't |
Are you able to reproduce this issue with the latest upstream version? I'm trying to figure out if it's a regression CRT side. |
@Swordfish90: I visited the repo link you posted but have no idea what it is or how exactly I would use it on macOS to reproduce the issue. |
I'm having this issue as well with a custom keyboard layout enabled via |
Temporary solutions for using programmer dvorak (or others) on Mac os:
|
Well I'm using karabiner and an uncommon layout. The keys of the layout work fine, but I have some combinations, such as fn + ijkl mapped to arrows, and for ijkl keys it does input ijkl instead of the expected cstn in my layout. Weird (and unusable). Same for my keys which have a secondary mapping with right cmd + key (asdf, etc.). |
On macOS, this app takes its inputs from scancodes, not letting the OS translate them to the (ascii?) codes as usual for other apps. Not sure if supporting multiple keyboard layouts is doable, but a lot of countries probably use (if only slightly, see france germany etc) different layouts.
The text was updated successfully, but these errors were encountered: