Open arrowmechanics opened 6 months ago
At the time it was very difficult to parse C, now we are data driven it is probably time to revisit.
On Sun, Mar 31, 2024, 18:08 Arrow Mechanics @.***> wrote:
Description
Keeping keymaps in this repo seems to be counterproductive, since there are two sources of default keymaps: here and in the firmware repo - ultimately this is duplicated code, its just that we keep it here in JSOHN, and there in C.
Wouldnt it be convenient if the configurator just downloaded the default keymap automatically from qmk_firmware source? Has this solution ever been discussed?
— Reply to this email directly, view it on GitHub https://github.com/qmk/qmk_configurator/issues/1338, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARLSU3HVWSCZPA2ZNUBKHTY3CXRXAVCNFSM6AAAAABFQ3TBM2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYTOMRZHE3TSMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Cool!
Adding an endpoint to the API for getting the default keymap parsed by CLI's c2json
seems like the most obvious solution - it keeps the code-operations on the API side, which already keeps itself updated with qmk_firmware
code changes, right?.
Do You think it's easily possible to add such endpoint to the API, since the code is not sourced? We could take care of the configurator part then - for fetching the keymap from the endpoint.
Description
Keeping keymaps in this repo seems to be counterproductive, since there are two sources of default keymaps: here and in the firmware repo - ultimately this is duplicated code, its just that we keep it here in JSOHN, and there in C.
Wouldnt it be convenient if the configurator just downloaded the default keymap automatically from qmk_firmware source? Has this solution ever been discussed?