Add Keygroups functions #669
Conversation
The various keyboard plugins implemented a way to jump to the bootloader on their own. However, this is a bootloader-specific functionality, and as such, it makes sense to have a common implementation. This patch does just that. Signed-off-by: Gergely Nagy <[email protected]>
Keygroups.h has been added to offer functions that allow determining if a given key is in a certain group. Signed-off-by: JD Lien <[email protected]>
Signed-off-by: JD Lien <[email protected]>
|
I'm not sure why I'm getting Travis build errors - probably some kind of scope or namespace issue. and so on. |
|
Have you given thought to how this interacts with non-US-ANSI key layouts? You're going to run into situations where a key that's an alphanumeric key in a US-ANSI layout is punctuation in a non-US layout and vice-versa. |
|
Yes, I have considered this somewhat, although I have limited exposure to such layouts. For example I am taking the Brazilian forward slash/question mark key and the language keys used in Japanese keyboards. Mostly these come from references to such keys in Kaleidoscope itself. I tried to be thorough. I’d love more input from international users who use very different layouts. |
|
Do you have specific examples of where a key gets remapped to a different kind of key? (Or can you point to a reference for these cases?) If there are cases where, for instance, letter keys get mapped to punctuation symbols or something, I suppose there could be an optional argument to specify a translation mode or something. |
|
I desperately wish I had a good reference for this -- then we could
generate proper mapping tables for all the different local/national
keyboard layouts.
Dvorak is one. (Semicolon becomes s, Q becomes ', etc)
French AZERTY is another (M becomes ,)
…On Thu, Jul 25, 2019 at 12:28 PM JD Lien ***@***.***> wrote:
Do you have specific examples of where a key gets remapped to a different
kind of key? (Or can you point to a reference for these cases?)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#669?email_source=notifications&email_token=AAALC2EH4P5BZKM4ZKABQZLQBH5FLA5CNFSM4IFNXZ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD22Q3LQ#issuecomment-515181998>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAALC2EFZTK2QIF46CLMDYLQBH5FLANCNFSM4IFNXZ3Q>
.
|
|
Well... I'm using the key names assigned by Keyboardio for this. If you define a Dvorak layout in firmware using the appropriate key names, this should work, correct? But if you define a normal QWERTY layout and let the OS remap everything, then that's when semicolon gets changed to S, etc, right? In that case it seems reasonable to rely on the key names... because how would you know if the OS has remapped a bunch of scan codes? I guess you'd have to make a different version of keygroups for each layout (or possibly pass a parameter that will adjust it appropriately). That sounds very hard to create and maintain for every possible remapping scheme. |
|
It is indeed a very, very complicated problem. And that's part of why I'm a
little bit hesitant about this as a core feature. There have been a couple
efforts to build lists of key definitions for non-English languages, but
they work by defining a layer on top of the USB HID definitions.
To be clear, your end goal is laudable and something I want. I just want to
be careful not to box ourselves into a corner with something that's going
to break for non-English on-device layouts.
…On Fri, Jul 26, 2019 at 11:39 AM JD Lien ***@***.***> wrote:
Well... I'm using the key names assigned by Keyboardio for this. If you
define a Dvorak layout in firmware using the appropriate key names, this
should work, correct? But if you define a normal QWERTY layout and let the
OS remap everything, then that's when semicolon gets changed to S, etc,
right?
In that case it seems reasonable to rely on the key names... because how
would you know if the OS has remapped a bunch of scan codes? I guess you'd
have to make a different version of keygroups for each layout (or possibly
pass a parameter that will adjust it appropriately). That sounds very hard
to create and maintain for every possible remapping scheme.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#669?email_source=notifications&email_token=AAALC2FTCS57QMNEVOERLUTQBNAHVA5CNFSM4IFNXZ32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD25MWSI#issuecomment-515558217>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAALC2APHUOYV7FL7433I7LQBNAHVANCNFSM4IFNXZ3Q>
.
|
I have added a series of functions in keygroups.h that are useful for determining which of several logical groupings a particular key might be in. This was integral to the way FunctionalColors works, and I think it might be useful to other plugin developers. I tried to be quite exhausive in coming up with these groups to include as many keys as I could find defined in Kaleidoscope, but perhaps there are other international keys I missed or something.
The functions I have come up with are the following:
keygroups. I have pored over the key definitions in Kaleidoscope, and models of various keyboards to be comprehensive in coming up with groups that make sense. (It turns out that there are a lot of media keys, but I only added the fairly common ones.)
Keygroups is integral to the way FunctionalColors works, as my intended use was to color keys of various types/groups differently, but not typically each individual key.
The functions I have come up with are the following
Note that I have not created a separate namespace for these functions, so that may be a desirable change depending on how it fits with the current firmware design.