fix: align keycode with QMK
Add more keycode alias to better align with QMK.
There are a lot that's still missing. If you want, I can add them all in this PR.
sure, please do
I have added all the missing keycode aliases.
I tried to maintain compatibility with the old code, but it seems like some are missing, and some are redundant. If you want to perfectly align with QMK and the HID spec (which is better imo), I can do that too. However, it means that there'll be breaking changes.
If you want to perfectly align with QMK and the HID spec (which is better imo), I can do that too
Yes, it's better to be aligned with HID spec.
However, it means that there'll be breaking changes.
Don't worry! The next release will be another breaking change ;)
Hi, is this pr considered complete?
Hi, is this pr considered complete?
Yes. If possible, some testing from the community would be great.
I've tested it. It works well!
However, when I'm configuring the keymap, I found that we should add some alias back, for example, -, =, [, ], etc. For me, using those symbols are more intuitive.
I think we don't have to be 100% aligned with QMK, having something that makes it easier to config is fine. Also, some documentations should be added to tell users the available symbols they could use.
Nice work! Would you mind adding those symbols back and adding a documentation which listing the available alias?
I found that we should add some alias back, for example,
-,=,[,], etc. For me, using those symbols are more intuitive.
While I agree that those are more intuitive and easy to read, it is easy to mistake similar keys. For example, for the minus symbol, there are 2 version, which is KpMinus and the normal Minus. If you still want it, we can go ahead and add the symbol alias for the normal variants, while ignoring their keypad and other counterparts.
Also, some documentations should be added to tell users the available symbols they could use.
I'll add that later, once the aliases are finalized to avoid extra works.
While I agree that those are more intuitive and easy to read, it is easy to mistake similar keys. For example, for the minus symbol, there are 2 version, which is KpMinus and the normal Minus.
We already have something similar, for example 0-9 and kp0-kp9. I don't think it will be a major issue. And yeah, that's why we need a list or a table for it. I believe it's worth to do it for better user experience 😄
@HaoboGu How does it looks now? If there is nothing to change, I'll go ahead with the docs.
looks great!
Looked it again, it's great for me now @HigherOrderLogic, please go for the docs :D
Thanks a lot!
Thanks for your effort! Can I merge this PR now?
Thanks for your effort! Can I merge this PR now?
There's still some less important keycodes missing from the docs. I'll get back to it in a few days when I have time.
I'm merging this PR since #372 depends on it a lot. If you have time to update docs further, please feel free to open another PR!
Thanks a loooooot for your effort!