mirror of
https://github.com/qmk/qmk_firmware.git
synced 2025-03-12 22:44:11 +00:00
Deploying to gh-pages from @ qmk/qmk_firmware@959f4cbb62 🚀
This commit is contained in:
parent
41bae9f114
commit
b6a10ac6c0
@ -21,7 +21,7 @@ This service is an asynchronous API for compiling custom keymaps. You POST some
|
||||
}
|
||||
```
|
||||
|
||||
As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports mulitple `LAYOUT` macros you can specify which macro to use.
|
||||
As you can see the payload describes all aspects of a keyboard necessary to create and generate a firmware. Each layer is a single list of QMK keycodes the same length as the keyboard's `LAYOUT` macro. If a keyboard supports multiple `LAYOUT` macros you can specify which macro to use.
|
||||
|
||||
## Submitting a Compile Job
|
||||
|
||||
|
@ -223,7 +223,7 @@ Check your environment and report problems only:
|
||||
|
||||
## `qmk format-json`
|
||||
|
||||
Formats a JSON file in a (mostly) human-friendly way. Will usually correctly detect the format of the JSON (info.json or keymap.json) but you can override this with `--format` if neccesary.
|
||||
Formats a JSON file in a (mostly) human-friendly way. Will usually correctly detect the format of the JSON (info.json or keymap.json) but you can override this with `--format` if necessary.
|
||||
|
||||
**Usage**:
|
||||
|
||||
|
@ -162,7 +162,7 @@ del(cli.config.<section>.<key>)
|
||||
|
||||
## Writing The Configuration File
|
||||
|
||||
The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberitely using `qmk config`.
|
||||
The configuration is not written out when it is changed. Most commands do not need to do this. We prefer to have the user change their configuration deliberately using `qmk config`.
|
||||
|
||||
You can use `cli.save_config()` to write out the configuration.
|
||||
|
||||
|
@ -24,7 +24,7 @@ Most of our style is pretty easy to pick up on, but right now it's not entirely
|
||||
* Readability is more important than consistency.
|
||||
* Follow the file's existing style. If the file is mixed, follow the style that makes sense for the section you are modifying.
|
||||
* When indenting, keep the hash at the start of the line and add whitespace between `#` and `if`, starting with 4 spaces after the `#`.
|
||||
* You can follow the indention level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
|
||||
* You can follow the indentation level of the surrounding C code, or preprocessor directives can have their own indentation levels. Choose the style that best communicates the intent of your code.
|
||||
|
||||
Here is an example for easy reference:
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
Most of our style follows PEP8 with some local modifications to make things less nit-picky.
|
||||
|
||||
* We target Python 3.7 for compatability with all supported platforms.
|
||||
* We target Python 3.7 for compatibility with all supported platforms.
|
||||
* We indent using four (4) spaces (soft tabs)
|
||||
* We encourage liberal use of comments
|
||||
* Think of them as a story describing the feature
|
||||
@ -21,7 +21,7 @@ You can use [yapf](https://github.com/google/yapf) to style your code. We provid
|
||||
|
||||
We don't have a hard and fast rule for when to use `import ...` vs `from ... import ...`. Understandability and maintainability is our ultimate goal.
|
||||
|
||||
Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatability module.
|
||||
Generally we prefer to import specific function and class names from a module to keep code shorter and easier to understand. Sometimes this results in a name that is ambiguous, and in such cases we prefer to import the module instead. You should avoid using the "as" keyword when importing, unless you are importing a compatibility module.
|
||||
|
||||
Imports should be one line per module. We group import statements together using the standard python rules- system, 3rd party, local.
|
||||
|
||||
|
@ -195,7 +195,7 @@ If you define these options you will enable the associated feature, which may in
|
||||
* `#define COMBO_TERM 200`
|
||||
* how long for the Combo keys to be detected. Defaults to `TAPPING_TERM` if not defined.
|
||||
* `#define COMBO_MUST_HOLD_MODS`
|
||||
* Flag for enabling extending timeout on Combos containing modifers
|
||||
* Flag for enabling extending timeout on Combos containing modifiers
|
||||
* `#define COMBO_MOD_TERM 200`
|
||||
* Allows for extending COMBO_TERM for mod keys while mid-combo.
|
||||
* `#define COMBO_MUST_HOLD_PER_COMBO`
|
||||
|
@ -374,7 +374,7 @@ This will clear all keys besides the mods currently pressed.
|
||||
This macro will register `KC_LALT` and tap `KC_TAB`, then wait for 1000ms. If the key is tapped again, it will send another `KC_TAB`; if there is no tap, `KC_LALT` will be unregistered, thus allowing you to cycle through windows.
|
||||
|
||||
```c
|
||||
bool is_alt_tab_active = false; // ADD this near the begining of keymap.c
|
||||
bool is_alt_tab_active = false; // ADD this near the beginning of keymap.c
|
||||
uint16_t alt_tab_timer = 0; // we will be using them soon.
|
||||
|
||||
enum custom_keycodes { // Make sure have the awesome keycode ready
|
||||
|
@ -259,12 +259,12 @@ void oled_render(void);
|
||||
void oled_set_cursor(uint8_t col, uint8_t line);
|
||||
|
||||
// Advances the cursor to the next page, writing ' ' if true
|
||||
// Wraps to the begining when out of bounds
|
||||
// Wraps to the beginning when out of bounds
|
||||
void oled_advance_page(bool clearPageRemainder);
|
||||
|
||||
// Moves the cursor forward 1 character length
|
||||
// Advance page if there is not enough room for the next character
|
||||
// Wraps to the begining when out of bounds
|
||||
// Wraps to the beginning when out of bounds
|
||||
void oled_advance_char(void);
|
||||
|
||||
// Writes a single character to the buffer at current cursor position
|
||||
|
@ -270,7 +270,7 @@ Configure the hardware via your `config.h`:
|
||||
| `ISSI_CONFIGURATION` | (Optional) Configuration for the Configuration Register | |
|
||||
| `ISSI_GLOBALCURRENT` | (Optional) Configuration for the Global Current Register | 0xFF |
|
||||
| `ISSI_PULLDOWNUP` | (Optional) Configuration for the Pull Up & Pull Down Register | |
|
||||
| `ISSI_TEMP` | (Optional) Configuration for the Tempature Register | |
|
||||
| `ISSI_TEMP` | (Optional) Configuration for the Temperature Register | |
|
||||
| `ISSI_PWM_ENABLE` | (Optional) Configuration for the PWM Enable Register | |
|
||||
| `ISSI_PWM_SET` | (Optional) Configuration for the PWM Setting Register | |
|
||||
| `ISSI_SCAL_RED` | (Optional) Configuration for the RED LEDs in Scaling Registers | 0xFF |
|
||||
|
Loading…
Reference in New Issue
Block a user