mirrors/opensteno_qmk
1
0
Fork 0
mirror of https://github.com/openstenoproject/qmk synced 2024-11-08 17:29:09 +00:00
Code Issues Projects Releases Packages Wiki Activity

Breaking changes for 2022q2. (#17221)

Browse source
This commit is contained in:
Nick Brassel 2022-05-29 07:50:21 +10:00 committed by GitHub
parent ebd4027883
commit d0af56da33
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 99 additions and 44 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

69
docs/ChangeLog/20220528.md
View file

@ -2,14 +2,72 @@
## Notable Features :id=notable-features
### TODO
### Caps Word ([#16588](https://github.com/qmk/qmk_firmware/pull/16588)) :id=caps-word
This is a new feature that allows for capslock-like functionality that turns itself off at the end of the word.
For instance, if you wish to type "QMK" without holding shift the entire time, you can either tap both left and right shift, or double-tap shift, to turn on _Caps Word_ -- then type `qmk` (lowercase) without holding shift. Once you hit any key other than `a`--`z`, `0`--`9`, `-`, `_`, delete, or backspace, this will go back to normal typing!
There are other activation mechanisms as well as configurable options like timeout and the like -- see the [Caps Word documentation](feature_caps_word.md) for more information.
### Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174)) :id=quantum-painter
QMK has had support for small OLED displays for some time now, but hasn't really gained too much ability to draw to panels other than the SSD1306 or SH1106 panels.
Quantum Painter is a new drawing subsystem available to suitable ARM and RISC-V boards that is capable of drawing to large panel RGB LCDs and RGB OLEDs. It also allows for a lot more flexibility with a larger set of drawing APIs -- lines, rectangles, circles, ellipses, text, images, and even animations.
The QMK CLI has new commands added to be able to generate images and fonts for Quantum Painter to digest -- it's even capable of converting animated gifs for display on screen.
See the [Quantum Painter documentation](quantum_painter.md) for more information on how to set up the displays as well as how to convert images and fonts.
!> Quantum Painter is not supported on AVR due to complexity and size constraints. Boards based on AVR such as ProMicro or Elite-C builds will not be able to leverage Quantum Painter.
### Encoder Mapping ([#13286](https://github.com/qmk/qmk_firmware/pull/13286)) :id=encoder-mapping
One of the long-standing complaints with Encoders is that there has been no easy way to configure them in user keymaps. [#13286](https://github.com/qmk/qmk_firmware/pull/13286) added support for [Encoder Mapping](feature_encoders.md#encoder-map), which allows users to define encoder functionality in a similar way to their normal keymap.
!> This is not yet supported by QMK Configurator. It is also unlikely to ever be supported by VIA.
## Changes Requiring User Action :id=changes-requiring-user-action
### `RESET` => `QK_BOOT` ([#17037](https://github.com/qmk/qmk_firmware/pull/17037)) :id=reset-2-qk_boot
QMK is always in the process of picking up support for new hardware platforms. One of the side-effects for future integrations has shown that QMK's usage of `RESET` as a keycode is causing naming collisions. As a result, [#17037](https://github.com/qmk/qmk_firmware/pull/17037) changed usages of `RESET` to the new keycode `QK_BOOT` in the majority of default-like keymaps. At this stage the old keycode is still usable but will likely be removed in the next breaking changes cycle. Users with keymaps containing `RESET` should also move to `QK_BOOT`.
### Sendstring keycode overhaul ([#16941](https://github.com/qmk/qmk_firmware/pull/16941)) :id=sendstring-keycodes
Some keycodes used with `SEND_STRING` and its relatives have been deprecated and may have their old keycode usages removed at a later date. The list of [deprecated keycodes](https://github.com/qmk/qmk_firmware/blob/ebd402788346aa6e88bde1486b2a835684d40d39/quantum/send_string_keycodes.h#L456-L505) should be consulted to determine if you're using one of the older names (the first identifier after `#define`) -- you should swap to the newer variant (the second identifier on the same line).
### Pillow Installation ([#17133](https://github.com/qmk/qmk_firmware/pull/17133)) :id=pillow-install
The merge of Quantum Painter added some new dependencies in the QMK CLI, most notably _Pillow_, which requires some installation in order for the CLI to function. If you've got an existing installation, you'll need to run some commands in order to get things working:
On Windows, if using _QMK MSYS_ or _msys2_, you'll need to run the following command:
```sh
pacman --needed --noconfirm --disable-download-timeout -S mingw-w64-x86_64-python-pillow
python3 -m pip install --upgrade qmk
```
On macOS:
```sh
brew update
brew upgrade qmk/qmk/qmk
```
On Linux or WSL:
```sh
python3 -m pip install --user --upgrade qmk
```
### Updated Keyboard Codebases :id=updated-keyboard-codebases
The following keyboards have had their source moved within QMK:
| Old Keyboard Name | New Keyboard Name |
|-----------------------|--------------------|
|----------------------|--------------------|
| absinthe | keyhive/absinthe |
| amj40 | amjkeyboard/amj40 |
| amj60 | amjkeyboard/amj60 |
@ -37,13 +95,9 @@ The following keyboards have had their source moved within QMK:
| wheatfield/split75 | mt/split75 |
| z150_bh | viktus/z150_bh |
## Notable core changes :id=notable-core
### TODO
---
## Full changelist
## Full changelist :id=full-changelist
Core:
* Quantum Painter ([#10174](https://github.com/qmk/qmk_firmware/pull/10174))
@ -120,6 +174,7 @@ Keyboards:
* Helix/rev2 move to split common ([#16723](https://github.com/qmk/qmk_firmware/pull/16723))
* Remove some layout exceptions ([#16957](https://github.com/qmk/qmk_firmware/pull/16957))
* Refactor legacy quantum keycodes in default-ish keymaps ([#17037](https://github.com/qmk/qmk_firmware/pull/17037))
* Refactor legacy quantum keycodes in default-ish keymaps ([#17150](https://github.com/qmk/qmk_firmware/pull/17150))
Keyboard fixes:
* gboards/gergoplex: move `COMBO_ENABLE` to keymap level ([#16667](https://github.com/qmk/qmk_firmware/pull/16667))

18
docs/breaking_changes.md
View file

@ -22,17 +22,17 @@ The breaking change period is when we will merge PR's that change QMK in dangero
## When is the next Breaking Change?
The next Breaking Change is scheduled for May 28, 2022.
The next Breaking Change is scheduled for August 27, 2022.
### Important Dates
* [x] 2022 Feb 26 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
* [ ] 2022 Apr 31 - `develop` closed to new PR's.
* [ ] 2022 Apr 31 - Call for testers.
* [ ] 2022 May 14 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
* [ ] 2022 May 26 - `master` is locked, no PR's merged.
* [ ] 2022 May 28 - Merge `develop` to `master`.
* [ ] 2022 May 28 - `master` is unlocked. PR's can be merged again.
* [x] 2022 May 28 - `develop` is tagged with a new release version. Each push to `master` is subsequently merged to `develop` by GitHub actions.
* [ ] 2022 Jul 31 - `develop` closed to new PR's.
* [ ] 2022 Jul 31 - Call for testers.
* [ ] 2022 Aug 13 - Last day for merges -- after this point `develop` is locked for testing and accepts only bugfixes
* [ ] 2022 Aug 25 - `master` is locked, no PR's merged.
* [ ] 2022 Aug 27 - Merge `develop` to `master`.
* [ ] 2022 Aug 27 - `master` is unlocked. PR's can be merged again.
## What changes will be included?
@ -43,7 +43,7 @@ If you want your breaking change to be included in this round you need to create
Criteria for acceptance:
* The PR is complete and ready to merge
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20220226`.
* The PR has a ChangeLog file describing the changes under `<qmk_firmware>/docs/Changelog/20220827`.
* This should be in Markdown format, with a name in the format `PR12345.md`, substituting the digits for your PR's ID.
* One strong recommendation that the ChangeLog document matches the PR description on GitHub, so as to ensure traceability.

2
docs/feature_encoders.md
View file

@ -67,7 +67,7 @@ Additionally, if one side does not have an encoder, you can specify `{}` for the
#define ENCODER_RESOLUTIONS_RIGHT { 4 }
```
## Encoder map
## Encoder map :id=encoder-map
Encoder mapping may be added to your `keymap.c`, which replicates the normal keyswitch layer handling functionality, but with encoders. Add this to your `rules.mk`: