Skip to content
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

Open
casperravenhorst opened this issue May 12, 2018 · 18 comments
Open

No support for dvorak (or supposedly others) keyboard layout #451

casperravenhorst opened this issue May 12, 2018 · 18 comments

Comments

@casperravenhorst
Copy link

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.

@whyboris
Copy link

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).

@whyboris
Copy link

whyboris commented Jul 5, 2018

Looks like the situation is a bit worse -- I'm on macOS with Dvorak layout turned on:
When I use the keyboard's asdf keys it types asdf characters in the terminal (sort-of expected since cool-retro-term can't use Dvorak yet),
but when I press the comma or a period (, or . ) keys, w, and v appear (the characters I'd expect if Dvorak was working).
Unsure if it's partially good news -- but it also means I can't access , or . in cool-retro-term 😕
When I switch to the standard QWERTY layout on the Mac, I can successfully type in the , and . characters using the default keyboard keys.

I wonder if it's getting fixed with this PR: #446 (see line 1027 and 1033)

@whyboris
Copy link

whyboris commented Jul 5, 2018

Is getting the Dvorak keyboard layout just a matter of adding some file here: https://github.com/Swordfish90/qmltermwidget/tree/master/lib/kb-layouts ?
If that's all it takes, I'm willing to create a file (provided I get a little guidance about how things work)

@whyboris
Copy link

Unbelievably -- today I launched the app by accident and it is working with Dvorak!!! 🎉
No idea why this difference. But very exciting!

@cascassette
Copy link

Not here. What did you do?

@whyboris
Copy link

The app hasn't been updated, so it might be some weird combination of settings.
I now suspect it might have something to do with the login screen on Mac:
Mac has a bug that when you are on Dvorak, the login screen might still be on QWERTY and vice versa -- they are independent. I'll play around and if I figure something out -- I'll share here. As of now I'm unsure.

@bayabyum
Copy link

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.

@dessalines
Copy link

I can verify that dvorak is working fine on linux.

@whyboris
Copy link

whyboris commented Jan 31, 2019

I'm on cool-retro-term version 1.1.1 and even though my Mac is set to Dvorak the home keys are asdf and jkls (QWERTY layout except for the : which ends up as s ⚠️ ).

Similarly the <, >, and ? get mapped to w, v, and z (as a Dvorak layout would).

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.

@wasp604
Copy link

wasp604 commented Feb 26, 2019

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.

@lraulin
Copy link

lraulin commented Mar 5, 2019

Programmer Dvorak works on 1.0.1 too!

@justinmayer
Copy link

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.

@mblarsen
Copy link

Ditto everything with Colemak 1.0.1 is working 1.1.1 isn't

@Swordfish90
Copy link
Owner

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.
https://github.com/lxqt/qtermwidget

@justinmayer
Copy link

@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.

@TheGrandmother
Copy link

I'm having this issue as well with a custom keyboard layout enabled via setxkbmap.
Although for me it works if i run setxkbmap in cool-retro-terminal

@find1dream
Copy link

Temporary solutions for using programmer dvorak (or others) on Mac os:

  1. Choose your keyboard input source as Australian (Depending on your keyboard, you should try another one if the result is not desired. )
  2. Install Karabiner-elements
  3. Import programmer dvorak from https://pqrs.org/osx/karabiner/complex_modifications/?q=programmer
  4. Enjoy

@g012
Copy link

g012 commented May 13, 2020

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.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests