muflax
/
ergodox-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

(minor cleanup; starting some changes in layout files)

partial-rewrite
Ben Blazak 2014-06-21 21:05:29 -07:00
parent 84fa10fb5f
commit 737428aec8
3 changed files with 19 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
firmware/keyboard/ergodox/layout/fragments/matrix-control.part.h
View File

@ -82,6 +82,7 @@ void kb__layout__exec_key(bool pressed, uint8_t row, uint8_t column) {
*
* TODO:
* - take care of the recording and such of macros :)
* - need to ignore layer-shift keys when recording
*/
void kb__layout__exec_key_layer( bool pressed,
uint8_t layer,
@ -98,12 +99,13 @@ void kb__layout__exec_key_layer( bool pressed,
// set default values
// - the key-function will not be able to see the values set previously
// - any function scheduled to run will be able to see the values set
// previously; but that may change in the future, so it shouldn't be
// relied on. if functions need to communicate with each other, they
// should share a file-local or global variable.
flags.key_type.sticky = false;
flags.key_type.layer_shift = false;
flags.key_type.layer_lock = false;
// by the immediately preceding function; but that may change in the
// future, so it shouldn't be relied on. if functions need to
// communicate with each other, they should share a file-local or global
// variable.
flags[0].key_type.sticky = false;
flags[0].key_type.layer_shift = false;
flags[0].key_type.layer_lock = false;
(*function)();

12
firmware/keyboard/ergodox/layout/fragments/variables.part.h
View File

@ -32,6 +32,16 @@ static layout_t layout PROGMEM;
* - `key_type.sticky`
* - `key_type.layer_shift`
* - `key_type.layer_lock`
*
* Terms:
* - A "sticky key" is one which, once pressed, remains pressed in software
* (whether or not the user holds it down) ... TODO
*
* TODO:
* - finish terms
* - change other code (in "./matrix-control.part.h") to actually use the fact
* that we have 2 of these now (so that there is an "old" version, and a
* version to update)
*/
static struct {
struct {
@ -39,5 +49,5 @@ static struct {
bool layer_shift : 1;
bool layer_lock : 1;
} key_type;
} flags;
} flags[2];

20
firmware/lib/layout/eeprom-macro/atmega32u4.c
View File

@ -55,26 +55,6 @@
* during a critical time being fairly low, and the consequence of (detected)
* data corruption hopefully more of an annoyance than anything else, I
* decided the effort (and extra EEMEM usage) wasn't worth it.
*
*
* TODO:
* - i was thinking before that the calling function need not ignore layer
* shift keys, or any other keys. now i think that layer keys (or at least
* layer shift keys) really should be ignored. not doing so may lead to all
* sorts of fun problems. for example, if the "begin/end recording" key is
* not on layer 0 (which it probably won't be), the last keys pressed (but
* not released) will most likely be layer shift keys -- but since these keys
* were not released before we stopped recording, there would be no record of
* their release, and the macro would therefore push that layer onto the
* layer stack, and never pop it off.
*
* - need to write something like:
* - `kb__layout__exec_key_layer()`
* - `kb__layout__exec_key()` could just look up the current layer
* (falling through for transparent keys), and then call
* `kb__layout__exec_key_layer()`. this would obviate the need for a
* separate `static get_layer(void)` function, since the
* functionality would essentially be separated out anyway.
*/