users/named the same as your keymap (ideally your GitHub username,
<name>) with the following structure:
/users/<name>/(added to the path automatically)
<name>, like this:
/users/jack/folder in the path, along with
rules.mkis one of the two files that gets processed automatically. This is how you add additional source files (such as
<name>.c) will be added when compiling.
<name>.cas the default source file to be added. And to add it, you need to add it the SRC in
<name>.c/.h to start off with, though.
/users/<name>/rules.mkfile will be included in the build after the
rules.mkfrom your keymap. This allows you to have features in your userspace
rules.mkthat depend on individual QMK features that may or may not be available on a specific keyboard.
define RGB_ENABLEin your keymap's
rules.mkand then check for the variable in your userspace's
mylayout-isoand add the following line to your layout's
config.hhere will be processed like the same file in your keymap folder. This is handled separately from the
<name>.hwon't be added in time to add settings (such as
#define TAPPING_TERM 100), and including the
<name.h>file in any
config.hfiles will result in compile issues.
layer_state_set_user()function. You can enable the Tri Layer State functionality on all of your boards, while also retaining the Tri Layer functionality in your
<name.c>file, you'd want to add this:
__attribute__ ((weak))part tells the compiler that this is a placeholder function that can then be replaced by a version in your
keymap.c. That way, you don't need to add it to your
keymap.c, but if you do, you won't get any conflicts because the function is the same name.
_keymappart here doesn't matter, it just needs to be something other than
_user, since those are already in use. So you could use
layer_state_set_fn, or anything else.
#ifdef MACROS_ENABLED, and then enable it per board. To do this, add this to your rules.mk
MACROS_ENABLEDto be defined for your keyboards (note the
-Din front of the name), and you could use
#ifdef MACROS_ENABLEDto check the status in your c/h files, and handle that code based on that.
MACROS_ENABLED = yesto the
rules.mkfor you keymap to enable this feature and the code in your userspace.
process_record_userfunction, you'd do something like this:
keymap.cfiles and replace
process_record_keymapinstead. This way, you can still use keyboard specific codes on those boards, and use your custom "global" keycodes as well. You'll also want to replace
NEW_SAFE_RANGEso that you wont have any overlapping keycodes
#include "<name>.h"to all of your keymap.c files. This allows you to use these new keycodes without having to redefine them in each keymap.
<name>.hfile. For instance:
<name>.cfile, and add this content to it:
rules.mkin your userspace folder:
KC_MAKEkeycode that can be used in any of your keymaps. And this keycode will output
make <keyboard>:<keymap>, making frequent compiling easier. And this will work with any keyboard and any keymap as it will output the current boards info, so that you don't have to type this out every time.
:flash) to the command. Holding Control will add some commands that will speed up compiling time by processing multiple files at once.
FLASH_BOOTLOADER = yesto the
rules.mkof that keymap.