qmk_firmware icon indicating copy to clipboard operation
qmk_firmware copied to clipboard

Updating the noodlepad_micro keymaps with custom keycodes

Open jessel92 opened this issue 1 year ago • 12 comments

Description

I added some custom keycodes to the noodlepad_micro keymaps. This also required me to modify the config,h file with the features implemented in the keycodes.

Forgive me if there is json version of some of the config.h options I enabled, I tried some and they didn't work, and I'm not really sure where to find if there is. Let me know!

Also, I'm sure the keycodes code is a little messy and inefficient, but they work great hahaha

Types of Changes

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

Issues Fixed or Closed by This PR

Checklist

  • [x] My code follows the code style of this project: C, Python
  • [x] 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.
  • [x] I have read the CONTRIBUTING document.
  • [ ] I have added tests to cover my changes.
  • [x] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

jessel92 avatar Feb 02 '24 23:02 jessel92

Any movement on this?

jessel92 avatar Feb 24 '24 00:02 jessel92

@drashna

EDIT: Disregard this, I only get this error after I run the qmk info -f json -kb themadnoodle/noodlepad_micro command

I'm also now getting THIS error that I was not getting before when I try to compile my keymap Did something change in the master branch since I opened this PR that would cause this issue?

/RP2040/ws2812_vendor.c:4:
drivers/ws2812.h:60:30: error: 'RGBLIGHT_LED_COUNT' undeclared here (not in a function); did you mean 'RGBLIGHT_LAYER_BLINK'?
   60 | #    define WS2812_LED_COUNT RGBLIGHT_LED_COUNT
      |                              ^~~~~~~~~~~~~~~~~~
platforms/chibios/drivers/vendor/RP/RP2040/ws2812_vendor.c:138:46: note: in expansion of macro 'WS2812_LED_COUNT'
  138 | static uint32_t                WS2812_BUFFER[WS2812_LED_COUNT];
      |                                              ^~~~~~~~~~~~~~~~
platforms/chibios/drivers/vendor/RP/RP2040/ws2812_vendor.c:138:32: error: 'WS2812_BUFFER' defined but not used [-Werror=unused-variable]
  138 | static uint32_t                WS2812_BUFFER[WS2812_LED_COUNT];
      |                                ^~~~~~~~~~~~~
cc1.exe: all warnings being treated as errors
 [ERRORS]
 |
 |
 |
make: *** [builddefs/common_rules.mk:373: .build/obj_themadnoodle_noodlepad_micro_via/ws2812_vendor.o] Error 1

jessel92 avatar Mar 20 '24 20:03 jessel92

@drashna Please let me know if we can get this merged as soon as possible. Because I have a PR with VIA that predates these custom codes, and they kindly agreed to wait for these changes to be merged before proceeding with their PR.

jessel92 avatar Mar 29 '24 04:03 jessel92

@drashna, I see everything was approved, but the PR was never merged. Is there any way we can get this merged?

jessel92 avatar Apr 04 '24 00:04 jessel92

At least two review approvals are needed before merge.

waffle87 avatar Apr 04 '24 00:04 waffle87

Also, see merge conflicts to be resolved.

waffle87 avatar Apr 04 '24 00:04 waffle87

At least two review approvals are needed before merge.

@waffle87 Ahh, I see ok, thanks for the info. @fauxpark This is a keymap update, isn't it? So shouldn't it be able to be merged straight into master??

jessel92 avatar Apr 04 '24 00:04 jessel92

There are changes to keyboard-level files.

fauxpark avatar Apr 04 '24 00:04 fauxpark

There are changes to keyboard-level files.

@fauxpark So, does that mean I need to wait until May for it to be merged into the master branch from develop, just because I added a few config changes?

Also, what's this branch conflict about? It wasn't there a few minutes ago, and how do I resolve it?

jessel92 avatar Apr 04 '24 01:04 jessel92

does that mean I need to wait until May for it to be merged into the master branch from develop

Yes. The merge conflicts are product of switching the target branch. See this doc.

waffle87 avatar Apr 04 '24 01:04 waffle87

@fauxpark @waffle87 ok, I think I was able to resolve it all. Correct? I rebased to develop, then recommitted the changes made in the master branch.

jessel92 avatar Apr 04 '24 01:04 jessel92

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[bot] avatar May 20 '24 01:05 github-actions[bot]

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[bot] avatar Jul 06 '24 01:07 github-actions[bot]

@fauxpark @waffle87 @drashna

This PR has been open since February 2, meaning it has now been pending for six months. I have promptly addressed every requested change within hours of the request. However, GitHub has attempted to mark this as stale twice, even though I am merely waiting for the next steps from everyone involved. Considering that this now ALSO needs to go through the develop branch before hitting the master, I would really appreciate it if we could resolve this as soon as possible (unless there is a way for us to get this merged directly to the master branch).

I am uncertain what else I need to do.

Additionally, due to the extremely long wait time, this PR has become somewhat outdated. I have new changes that need to be added once this is merged, along with a new keypad PR that I can't open until this is merged.

I am trying to remain patient, understanding that you all have a lot on your plate and that open-source work can be challenging. However, this prolonged process has significantly thrown a wrench in my business at this point.

jessel92 avatar Jul 07 '24 05:07 jessel92

As of August 26, 2024, qmk/qmk_firmware is no longer accepting VIA-enabled keymaps as these have now transitioned to a repository under the VIA team's control.

As you've submitted a PR containing via or VIA-enabled keymap(s), this is your notice that they should be removed from this PR. You should now submit a secondary PR to the VIA QMK Userspace repository with your associated via or VIA-enabled keymaps instead.

tzarc avatar Aug 26 '24 10:08 tzarc

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[bot] avatar Oct 11 '24 02:10 github-actions[bot]

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]

github-actions[bot] avatar Nov 10 '24 02:11 github-actions[bot]