add rgb-effects qmk sub command

[mguentner]

Description

I have enabled a few more effects for my keyboard and the list of effects that is selectable in the VIA frontend does not match the effects in the firmware any longer.
Since the enum rgb_matrix_effects is highly dynamic and depends on the specific keyboard/keymap and can also configured on various levels it is best to directly parse the enum that is the result of the preprocessor and the input of the compiler.

This is achieved by also emitting the temporary files (.i) when building a firmware. These files can then later be consumed by other tools, in this case with a new subcommand in qmk.

Example output:

❯ qmk rgb-effects -kb keychron/q1/ansi_stm32l432_encoder -km via
[
    ["00. NONE", 0],
    ["01. SOLID_COLOR", 1],
    ["02. ALPHAS_MODS", 2],
    ["03. GRADIENT_UP_DOWN", 3],
    ["04. GRADIENT_LEFT_RIGHT", 4],
    ["05. BREATHING", 5],
    ["06. BAND_SAT", 6],
    ["07. BAND_VAL", 7],
    ["08. BAND_PINWHEEL_SAT", 8],
    ["09. BAND_PINWHEEL_VAL", 9],
    ["10. BAND_SPIRAL_SAT", 10],
    ["11. BAND_SPIRAL_VAL", 11],
    ["12. CYCLE_ALL", 12],
    ["13. CYCLE_LEFT_RIGHT", 13],
    ["14. CYCLE_UP_DOWN", 14],
    ["15. RAINBOW_MOVING_CHEVRON", 15],
    ["16. CYCLE_OUT_IN", 16],
    ["17. CYCLE_OUT_IN_DUAL", 17],
    ["18. CYCLE_PINWHEEL", 18],
    ["19. CYCLE_SPIRAL", 19],
    ["20. DUAL_BEACON", 20],
    ["21. RAINBOW_BEACON", 21],
    ["22. RAINBOW_PINWHEELS", 22],
    ["23. RAINDROPS", 23],
    ["24. JELLYBEAN_RAINDROPS", 24],
    ["25. HUE_BREATHING", 25],
    ["26. HUE_PENDULUM", 26],
    ["27. HUE_WAVE", 27],
    ["28. PIXEL_RAIN", 28],
    ["29. PIXEL_FLOW", 29],
    ["30. PIXEL_FRACTAL", 30],
    ["31. TYPING_HEATMAP", 31],
    ["32. DIGITAL_RAIN", 32],
    ["33. SOLID_REACTIVE_SIMPLE", 33],
    ["34. SOLID_REACTIVE", 34],
    ["35. SOLID_REACTIVE_WIDE", 35],
    ["36. SOLID_REACTIVE_MULTIWIDE", 36],
    ["37. SOLID_REACTIVE_CROSS", 37],
    ["38. SOLID_REACTIVE_MULTICROSS", 38],
    ["39. SOLID_REACTIVE_NEXUS", 39],
    ["40. SOLID_REACTIVE_MULTINEXUS", 40],
    ["41. SPLASH", 41],
    ["42. MULTISPLASH", 42],
    ["43. SOLID_SPLASH", 43],
    ["44. SOLID_MULTISPLASH", 44],
    ["45. RANDOM_FILL", 45]
]

This can then be copied into the VIA json as the options list for id_qmk_rgb_matrix_effect.

@lalalademaxiya1 pinging you as the keychron VIA json files are often brought up as a reference. Maybe you have a similar tool
and/or would benefit from this.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[drashna]

While this is a great idea, it's not the direction we plan on going.

Specifically, QMK XAP is designed to handle cases like this, and handles it better (enabled modes and such being embedded in the firmware, requiring no additional tooling like this).

For more details on XAP: #13733

And feel free to jump onto discord, as we have a channel specifically for discussing xap development.

[mguentner]

@drashna I understand. The current behavior of QMK and VIA is not ergonomic at all. I do not understand why there is even a default list in v3 VIA today as most keyboard configs in QMK do not have this particular list enabled. So in the end users / devs need to come up with this list by hand anyway while not making a mistake that will shift.

XAP seems like the sane way to handle this. This PR is merely a hack to be able to work with the current state. But I can also see why you do not want to merge it because it would further advance the project into an undesired direction.
As I also do not see a way to maintain it in some contrib repo, I have done a final force push so that the code is potentially mergeable (linter should be happy now).
If someone wants to use it in their branch until XAP arrives, they can do so by cherry-picking from this one.

[github-actions]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[github-actions]

Thank you for your contribution!
This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready.
// [stale-action-closed]