[Keymap] add userspace folder, adding and updating keymaps.

[mkillewald]

Description

• Adding userspace folder users/mkillewald
• Adding keymap keychron/q2/ansi_encoder/keymaps/mkillewald (stm32l432)
• Adding keymap keychron/q1/ansi_encoder/keymaps/mkillewald (atmega32u4)
• Updating keymap keychron/q1/ansi/keymaps/mkillewald (atmega32u4)
• Renaming keychron/q1/iso/keymaps/mkillewald_iso to /keymaps/mkillewald and updating keymap to match version and features of ANSI keymap

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

[adophoxia]

Opening and closing new PRs isn't going to help this one as fragmentation will occur if this goes on. I suggest you stick to your previous PR and work from there.

[mkillewald]

Sorry, If I've done something wrong. I'm a lone amateur developer figuring things out as I go. I've deleted the branch the previous PR was based off of. This branch has my updated code with newer features. My thinking was to close the previous PR and delete the old branch since the code was outdated rather then to let it get merged and then come back and update it with this one. Perhaps, I should have merged this new feature branch with the old one on the old PR.

[mkillewald]

Have added userspace folder.

[mkillewald]

I previously had created separate branches for each keyboard I was working on with separate PRs to boot. I have now merged my branches (mkillewald_q1 and mkillewald_q1se) into this branch (mkillewald_q2_custom) for a single PR.

[drashna]

You should move this to your userspace. It will still get picked up there, and you don't have to have 10 copies of it

[mkillewald]

@drashna I am using two different dictionary files, the 400 entry and the smaller 77 entry file. I've moved the 400 entry dictionary into my userspace folder because I would like this to be my default for in the future. Unfortunately, at this time, I have only one keymap (the q2) that utilizes the 400 entry dictionary. The Q1 keymaps (using the atmega32u4) are utilizing the smaller 77 entry file because they are near the firmware size limit. So I still have many copies of the same file. Perhaps there is a way to move both dictionary files to the userspace folder and specify which dictionary file to pull from?

[drashna]

you can still use the same file for both. Eg:

#if defined(__AVR__)
// avr friendly dictionary
#else
// arm dictionary
#endif

This would allow you to have one file for both configs. Either option is fine, though.

[mkillewald]

Will be adding a q1v2 keymap to this if/when #20416 is merged

[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.

[zvecr]

Unfortunately since this PRs creation, QMK has changed its stance on accepting user keymaps to the repository.

qmk/qmk_firmware is no longer accepting PRs for keymaps other than for manufacturer-supported keymaps. User keymap workflow has been documented here for several years. This change is to progressively reduce the maintenance burden on the project, and to allow us to focus on the core features of QMK.

In the near future we will be providing a more user focused workflow for keymaps, but till then the suggestion is to keep changes in your own fork.

While we appreciate the time that was taken on this PR, hopefully you understand we are closing it, so that QMK can improve in the long term.