rmk icon indicating copy to clipboard operation
rmk copied to clipboard

fix: align keycode with QMK

Open HigherOrderLogic opened this issue 8 months ago • 12 comments

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.

HigherOrderLogic avatar Apr 12 '25 06:04 HigherOrderLogic

sure, please do

HaoboGu avatar Apr 12 '25 09:04 HaoboGu

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.

HigherOrderLogic avatar Apr 12 '25 15:04 HigherOrderLogic

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

HaoboGu avatar Apr 13 '25 14:04 HaoboGu

Hi, is this pr considered complete?

HaoboGu avatar Apr 15 '25 15:04 HaoboGu

Hi, is this pr considered complete?

Yes. If possible, some testing from the community would be great.

HigherOrderLogic avatar Apr 15 '25 15:04 HigherOrderLogic

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.

HaoboGu avatar Apr 16 '25 07:04 HaoboGu

Nice work! Would you mind adding those symbols back and adding a documentation which listing the available alias?

HaoboGu avatar Apr 16 '25 07:04 HaoboGu

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.

HigherOrderLogic avatar Apr 16 '25 14:04 HigherOrderLogic

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 avatar Apr 16 '25 15:04 HaoboGu

@HaoboGu How does it looks now? If there is nothing to change, I'll go ahead with the docs.

HigherOrderLogic avatar Apr 17 '25 10:04 HigherOrderLogic

looks great!

HaoboGu avatar Apr 17 '25 12:04 HaoboGu

Looked it again, it's great for me now @HigherOrderLogic, please go for the docs :D

Thanks a lot!

HaoboGu avatar Apr 19 '25 07:04 HaoboGu

Thanks for your effort! Can I merge this PR now?

HaoboGu avatar May 20 '25 02:05 HaoboGu

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.

HigherOrderLogic avatar May 20 '25 06:05 HigherOrderLogic

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!

HaoboGu avatar May 26 '25 11:05 HaoboGu