sporq/kmk_firmware
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
64888f1df8
kmk_firmware/user_keymaps/klardotsh/threethree_matrix_pyboard.py

69 lines
1.5 KiB
Python
Raw Normal View History

Massive refactor largely to support Unicode on Mac This does a bunch of crazy stuff: - The ability to set a unicode mode (right now only Linux+ibus or MacOS-RALT) in the keymap. This will be changeable at runtime soon, to allow a single keyboard to be able to send table flips and whatever other crazy stuff on any OS the board is plugged into (something that's not currently doable on QMK, so yay us?) - As part of the above, there is now just one user-facing macro for unicode codepoint submission, `kmk.common.macros.unicode.unicode_sequence`. Users should never use the platform-specific macros, partly because they just outright won't work. There's all sorts of fun stuff in these methods now, thank goodness MicroPython supports the `yield from` construct. - Keycode (these should really be renamed Keysym or something) objects that are intended to not be pressed, or not be released. Right now these properties are completely ignored if not part of a macro, and it's probably sane to keep it that way. This was necessary to support MacOS's "hold RALT while typing the codepoint characters" flow. - Other refactor-y bits, like moving macro support to `kmk/common` rather than sitting at the top level of the tree. One day `kmk/common` may make sense to surface at top level `kmk/`, but that's a discussion for another day.
2018-10-01 04:33:23 +02:00
from kmk.common.consts import DiodeOrientation, UnicodeModes
Make user keymaps fully declarative This removes the need for the user to define... most things, honestly. Notably, `main()` is no longer the end user's responsibility. This also allows us to do fun stuff going forward like validating keymaps for sanity (ex: the key assigned to `KC_MO(x)` should be assigned to `KC_TRNS` on the target layer or the user will never be able to escape that layer). This also disambiguates `BOARD` to always refer to an actual slab of silicon, renaming to `USER_KEYMAP`. Entrypoints are now a bit more wild, and mostly-unsupported boards no longer have working entrypoints. It's probably just time to scrap those boards for now (until we have BLE HID and/or bitbang USB HID, at least).
2018-09-23 07:36:28 +02:00
from kmk.common.keycodes import KC
Support a massively-enhanced SEND_STRING equivalent
2018-10-01 06:14:30 +02:00
from kmk.common.macros.simple import send_string, simple_key_sequence
Massive refactor largely to support Unicode on Mac This does a bunch of crazy stuff: - The ability to set a unicode mode (right now only Linux+ibus or MacOS-RALT) in the keymap. This will be changeable at runtime soon, to allow a single keyboard to be able to send table flips and whatever other crazy stuff on any OS the board is plugged into (something that's not currently doable on QMK, so yay us?) - As part of the above, there is now just one user-facing macro for unicode codepoint submission, `kmk.common.macros.unicode.unicode_sequence`. Users should never use the platform-specific macros, partly because they just outright won't work. There's all sorts of fun stuff in these methods now, thank goodness MicroPython supports the `yield from` construct. - Keycode (these should really be renamed Keysym or something) objects that are intended to not be pressed, or not be released. Right now these properties are completely ignored if not part of a macro, and it's probably sane to keep it that way. This was necessary to support MacOS's "hold RALT while typing the codepoint characters" flow. - Other refactor-y bits, like moving macro support to `kmk/common` rather than sitting at the top level of the tree. One day `kmk/common` may make sense to surface at top level `kmk/`, but that's a discussion for another day.
2018-10-01 04:33:23 +02:00
from kmk.common.macros.unicode import unicode_sequence
Abstract away platform-dependent pin references Quote taken straight from the docstring of get_pin: >Cross-platform method to find a pin by string. > >The pin definitions are platform-dependent, but this provides >a way to say "I'm using pin D20" without rolling a D20 and >having to actually learn MicroPython/CircuitPython and the >differences in how they handle pinouts. > >This also makes the keymap sanity checker actually work for >CircuitPython boards, since it's not possible in CPY to >define a module stub for `board` that uses Passthrough >natively (which is how the MicroPython stub worked originally)
2018-10-07 10:40:09 +02:00
from kmk.common.pins import Pin as P
Make user keymaps fully declarative This removes the need for the user to define... most things, honestly. Notably, `main()` is no longer the end user's responsibility. This also allows us to do fun stuff going forward like validating keymaps for sanity (ex: the key assigned to `KC_MO(x)` should be assigned to `KC_TRNS` on the target layer or the user will never be able to escape that layer). This also disambiguates `BOARD` to always refer to an actual slab of silicon, renaming to `USER_KEYMAP`. Entrypoints are now a bit more wild, and mostly-unsupported boards no longer have working entrypoints. It's probably just time to scrap those boards for now (until we have BLE HID and/or bitbang USB HID, at least).
2018-09-23 07:36:28 +02:00
from kmk.entrypoints.handwire.pyboard import main
Abstract away platform-dependent pin references Quote taken straight from the docstring of get_pin: >Cross-platform method to find a pin by string. > >The pin definitions are platform-dependent, but this provides >a way to say "I'm using pin D20" without rolling a D20 and >having to actually learn MicroPython/CircuitPython and the >differences in how they handle pinouts. > >This also makes the keymap sanity checker actually work for >CircuitPython boards, since it's not possible in CPY to >define a module stub for `board` that uses Passthrough >natively (which is how the MicroPython stub worked originally)
2018-10-07 10:40:09 +02:00
cols = (P.X10, P.X11, P.X12)
rows = (P.X1, P.X2, P.X3)
Make user keymaps fully declarative This removes the need for the user to define... most things, honestly. Notably, `main()` is no longer the end user's responsibility. This also allows us to do fun stuff going forward like validating keymaps for sanity (ex: the key assigned to `KC_MO(x)` should be assigned to `KC_TRNS` on the target layer or the user will never be able to escape that layer). This also disambiguates `BOARD` to always refer to an actual slab of silicon, renaming to `USER_KEYMAP`. Entrypoints are now a bit more wild, and mostly-unsupported boards no longer have working entrypoints. It's probably just time to scrap those boards for now (until we have BLE HID and/or bitbang USB HID, at least).
2018-09-23 07:36:28 +02:00
diode_orientation = DiodeOrientation.COLUMNS
Massive refactor largely to support Unicode on Mac This does a bunch of crazy stuff: - The ability to set a unicode mode (right now only Linux+ibus or MacOS-RALT) in the keymap. This will be changeable at runtime soon, to allow a single keyboard to be able to send table flips and whatever other crazy stuff on any OS the board is plugged into (something that's not currently doable on QMK, so yay us?) - As part of the above, there is now just one user-facing macro for unicode codepoint submission, `kmk.common.macros.unicode.unicode_sequence`. Users should never use the platform-specific macros, partly because they just outright won't work. There's all sorts of fun stuff in these methods now, thank goodness MicroPython supports the `yield from` construct. - Keycode (these should really be renamed Keysym or something) objects that are intended to not be pressed, or not be released. Right now these properties are completely ignored if not part of a macro, and it's probably sane to keep it that way. This was necessary to support MacOS's "hold RALT while typing the codepoint characters" flow. - Other refactor-y bits, like moving macro support to `kmk/common` rather than sitting at the top level of the tree. One day `kmk/common` may make sense to surface at top level `kmk/`, but that's a discussion for another day.
2018-10-01 04:33:23 +02:00
unicode_mode = UnicodeModes.LINUX
Make user keymaps fully declarative This removes the need for the user to define... most things, honestly. Notably, `main()` is no longer the end user's responsibility. This also allows us to do fun stuff going forward like validating keymaps for sanity (ex: the key assigned to `KC_MO(x)` should be assigned to `KC_TRNS` on the target layer or the user will never be able to escape that layer). This also disambiguates `BOARD` to always refer to an actual slab of silicon, renaming to `USER_KEYMAP`. Entrypoints are now a bit more wild, and mostly-unsupported boards no longer have working entrypoints. It's probably just time to scrap those boards for now (until we have BLE HID and/or bitbang USB HID, at least).
2018-09-23 07:36:28 +02:00
Support a massively-enhanced SEND_STRING equivalent
2018-10-01 06:14:30 +02:00
MACRO_TEST_SIMPLE = simple_key_sequence([
Support a simple macro of a sequence of keycodes (basis for SEND_STRING)
2018-10-01 03:03:43 +02:00
KC.LSHIFT(KC.H),
KC.E,
KC.L,
KC.L,
KC.O,
KC.SPACE,
Add support for millisecond delays within a macro sequence
2018-10-01 06:34:16 +02:00
KC.MACRO_SLEEP_MS(500),
Support a simple macro of a sequence of keycodes (basis for SEND_STRING)
2018-10-01 03:03:43 +02:00
KC.LSHIFT(KC.K),
KC.LSHIFT(KC.M),
KC.LSHIFT(KC.K),
KC.EXCLAIM,
])
Support a massively-enhanced SEND_STRING equivalent
2018-10-01 06:14:30 +02:00
MACRO_TEST_STRING = send_string("Hello! from, uhhhh, send_string | and some other WEIRD STUFF` \\ like this' \"\t[]")
Massive refactor largely to support Unicode on Mac This does a bunch of crazy stuff: - The ability to set a unicode mode (right now only Linux+ibus or MacOS-RALT) in the keymap. This will be changeable at runtime soon, to allow a single keyboard to be able to send table flips and whatever other crazy stuff on any OS the board is plugged into (something that's not currently doable on QMK, so yay us?) - As part of the above, there is now just one user-facing macro for unicode codepoint submission, `kmk.common.macros.unicode.unicode_sequence`. Users should never use the platform-specific macros, partly because they just outright won't work. There's all sorts of fun stuff in these methods now, thank goodness MicroPython supports the `yield from` construct. - Keycode (these should really be renamed Keysym or something) objects that are intended to not be pressed, or not be released. Right now these properties are completely ignored if not part of a macro, and it's probably sane to keep it that way. This was necessary to support MacOS's "hold RALT while typing the codepoint characters" flow. - Other refactor-y bits, like moving macro support to `kmk/common` rather than sitting at the top level of the tree. One day `kmk/common` may make sense to surface at top level `kmk/`, but that's a discussion for another day.
2018-10-01 04:33:23 +02:00
ANGRY_TABLE_FLIP = unicode_sequence([
Support the real reason we're all here: unicode key sequences (Linux only). Basically takes the same output style as klardotsh/qmk_emote_macro_generator outputs
2018-10-01 03:20:18 +02:00
"28",
"30ce",
"ca0",
"75ca",
"ca0",
"29",
"30ce",
"5f61",
"253b",
"2501",
"253b",
])
Make user keymaps fully declarative This removes the need for the user to define... most things, honestly. Notably, `main()` is no longer the end user's responsibility. This also allows us to do fun stuff going forward like validating keymaps for sanity (ex: the key assigned to `KC_MO(x)` should be assigned to `KC_TRNS` on the target layer or the user will never be able to escape that layer). This also disambiguates `BOARD` to always refer to an actual slab of silicon, renaming to `USER_KEYMAP`. Entrypoints are now a bit more wild, and mostly-unsupported boards no longer have working entrypoints. It's probably just time to scrap those boards for now (until we have BLE HID and/or bitbang USB HID, at least).
2018-09-23 07:36:28 +02:00
keymap = [
[
Add advanced layers. These will need more testing and some ported to tapdance. The bigest case of this would be TT
2018-09-28 23:35:52 +02:00
[KC.MO(1), KC.GESC, KC.RESET],
[KC.LT(2, KC.EXCLAIM), KC.HASH, KC.ENTER],
[KC.TT(3), KC.SPACE, KC.LSHIFT],
Make user keymaps fully declarative This removes the need for the user to define... most things, honestly. Notably, `main()` is no longer the end user's responsibility. This also allows us to do fun stuff going forward like validating keymaps for sanity (ex: the key assigned to `KC_MO(x)` should be assigned to `KC_TRNS` on the target layer or the user will never be able to escape that layer). This also disambiguates `BOARD` to always refer to an actual slab of silicon, renaming to `USER_KEYMAP`. Entrypoints are now a bit more wild, and mostly-unsupported boards no longer have working entrypoints. It's probably just time to scrap those boards for now (until we have BLE HID and/or bitbang USB HID, at least).
2018-09-23 07:36:28 +02:00
],
[
[KC.TRNS, KC.B, KC.C],
Enable switching Unicode modes at runtime; lots of Keycode cleanup again
2018-10-01 05:21:42 +02:00
[KC.NO, KC.D, KC.E],
[KC.F, KC.G, KC.H],
Make user keymaps fully declarative This removes the need for the user to define... most things, honestly. Notably, `main()` is no longer the end user's responsibility. This also allows us to do fun stuff going forward like validating keymaps for sanity (ex: the key assigned to `KC_MO(x)` should be assigned to `KC_TRNS` on the target layer or the user will never be able to escape that layer). This also disambiguates `BOARD` to always refer to an actual slab of silicon, renaming to `USER_KEYMAP`. Entrypoints are now a bit more wild, and mostly-unsupported boards no longer have working entrypoints. It's probably just time to scrap those boards for now (until we have BLE HID and/or bitbang USB HID, at least).
2018-09-23 07:36:28 +02:00
],
[
Support the real reason we're all here: unicode key sequences (Linux only). Basically takes the same output style as klardotsh/qmk_emote_macro_generator outputs
2018-10-01 03:20:18 +02:00
[KC.VOLU, KC.MUTE, ANGRY_TABLE_FLIP],
Support a massively-enhanced SEND_STRING equivalent
2018-10-01 06:14:30 +02:00
[KC.TRNS, KC.PIPE, MACRO_TEST_SIMPLE],
Enable switching Unicode modes at runtime; lots of Keycode cleanup again
2018-10-01 05:21:42 +02:00
[KC.VOLD, KC.P, MACRO_TEST_STRING],
],
[
[KC.NO, KC.UC_MODE_NOOP, KC.C],
[KC.NO, KC.UC_MODE_LINUX, KC.E],
[KC.TRNS, KC.UC_MODE_MACOS, KC.H],
Make user keymaps fully declarative This removes the need for the user to define... most things, honestly. Notably, `main()` is no longer the end user's responsibility. This also allows us to do fun stuff going forward like validating keymaps for sanity (ex: the key assigned to `KC_MO(x)` should be assigned to `KC_TRNS` on the target layer or the user will never be able to escape that layer). This also disambiguates `BOARD` to always refer to an actual slab of silicon, renaming to `USER_KEYMAP`. Entrypoints are now a bit more wild, and mostly-unsupported boards no longer have working entrypoints. It's probably just time to scrap those boards for now (until we have BLE HID and/or bitbang USB HID, at least).
2018-09-23 07:36:28 +02:00
],
]
Reference in New Issue Copy Permalink