Skip to content

Commit

Permalink
add support for non-qwerty layout
Browse files Browse the repository at this point in the history
The support is done via a class that consist of a mapping from KC to
others.

Such mapping are similar to what is done in QMK therefore a script is
provided to bootstrap their definition.

Existing doc on how to add internationla keycode is removed as those
keycode are now all integrated in the base KC definition.
  • Loading branch information
crazyiop committed Jun 11, 2022
1 parent 80b44b5 commit 30be0e3
Show file tree
Hide file tree
Showing 2 changed files with 49 additions and 29 deletions.
67 changes: 38 additions & 29 deletions docs/international.md
Original file line number Diff line number Diff line change
@@ -1,35 +1,44 @@
# International Keycodes
International extension adds keys for non US layouts. It can simply be added to
the extensions list.
# Non QWERTY layout
If your computer is not configured (at the OS level) to use the QWERTY layout, you will have a hard time making your layers as `KC.Q` will for example output an `a` on an azerty layout.

To not have to deal yourself with all those translation we provide the `KeyMapConverter` class. It is intented to be subclassed for your layout, you then only have to define your mapping.

Note: There is no consensus on this (and currently not many user of that feature). Keep in mind that this might evolve, so keep an eyes on this when you update KMK.

The mapping is a relation:
- from what you want to use in the keymap (= what you see on your keyboard key)
- to what it should send as qwerty (= what your computer will print for this key if you set it up to use a QWERTY layout)


## Example use
For a french AZERTY layout you would have something like:

file: /kmk/extensions/keymap_extras/keymap_french.py
```python
from kmk.extensions.international import International
keyboard.extensions.append(International())
from kmk.keys import KC
from kmk.extensions.keymap_extras.base import KeyMapConverter

class AZERTY(KeyMapConverter):
MAPPING = {
'A': KC.Q,
'Z': KC.W,
'E': KC.E,
'R': KC.R,
'T': KC.T,
'Y': KC.Y,
...
}
```

## Keycodes

|Key |Aliases |Description |
|-----------------------|--------------------|-----------------------------------------------|
|`KC.NONUS_HASH` |`KC.NUHS` |Non-US `#` and `~` |
|`KC.NONUS_BSLASH` |`KC.NUBS` |Non-US `\` and <code>&#124;</code> |
|`KC.INT1` |`KC.RO` |JIS `\` and <code>&#124;</code> |
|`KC.INT2` |`KC.KANA` |JIS Katakana/Hiragana |
|`KC.INT3` |`KC.JYEN` |JIS `¥` |
|`KC.INT4` |`KC.HENK` |JIS Henkan |
|`KC.INT5` |`KC.MHEN` |JIS Muhenkan |
|`KC.INT6` | |JIS Numpad `,` |
|`KC.INT7` | |International 7 |
|`KC.INT8` | |International 8 |
|`KC.INT9` | |International 9 |
|`KC.LANG1` |`KC.HAEN` |Hangul/English |
|`KC.LANG2` |`KC.HANJ` |Hanja |
|`KC.LANG3` | |JIS Katakana |
|`KC.LANG4` | |JIS Hiragana |
|`KC.LANG5` | |JIS Zenkaku/Hankaku |
|`KC.LANG6` | |Language 6 |
|`KC.LANG7` | |Language 7 |
|`KC.LANG8` | |Language 8 |
|`KC.LANG9` | |Language 9 |
file: /code.py
```python
from kmk.extensions.keymap_extras.keymap_french import AZERTY

FR = AZERTY()
keyboard.keymap = [[FR.A, FR.Z, FR.E, FR.R, FR.T, FR.Y, ...]]
```

## Generating a missing layout
Making such mapping is very tedious. But a script to generate it from the equivlaent files from QMK can be found [here](https://github.com/crazyiop/kmk_keymap_extras)

Warning: The generated layout **need to be tested** and might need to be refined but that should save you quite some work.
11 changes: 11 additions & 0 deletions kmk/extensions/keymap_extras/base.py
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
from kmk.keys import KC


class KeyMapConverter:
'''Class to allow easy definition of alternative layout'''

def __getattr__(self, key):
try:
return self.MAPPING[key]
except KeyError:
return getattr(KC, key)

0 comments on commit 30be0e3

Please sign in to comment.