Always populate trigger list based on key down events

[jambl3r]

Arguments for from @GfEW in #2077

Press "Tap to record trigger", type e. g. Alt+F11 (i. e. Alt_down,F11_down,F11_up,Alt_up, sticking below with whichever Alt key side you choose), and add some action - for the sake of this test e. g. toggle flashlight -, then save the map and type the trigger.
--> Nothing happens.

This is currently intended behaviour. The order of the 'up' events is what determines the order in the list. This situation where nothing happens but the user expected it to (because they replicated their trigger exactly after recording) can be 'solved' with #591 'together in any order' being the default option.

That doesn't make sense to me, because the behaviour encountered in step 1 is inconsistent:

• recording learns "up" events
• triggering acts on "down" events.

I think that whichever way KeyMapper chooses, it should stick with it, to ensure recorded triggers are immediately functional without manual reordering. (This worked fine in 3.2.1.)

Whilst ignoring the order of trigger keys would "cover up" the inconsistency discussed above, it might better be resolved (if it exists on A11+).

I find it hard to believe we're talking about the same thing here, because the inconsistency between record and replay event modes really makes no sense.

I've just checked again on a phone with KeyMapper v3.2.1-foss 132 and BT keyboard connected: "record" and "retype" both register key "down" events on that device, and ignore key "up" events.

In v4.0.5-foss 247 however, every multi key trigger I record initially does not work when retyped as recorded. It becomes functional only after manually reversing the displayed order of trigger keys. That discrepancy can't seriously be intentional.

It would work just as fine (well, almost) if both used "up" events instead, but that's not what v4.0.5-foss 247 does here.

[GfEW]

@jambl3r
Thanks for filing this. You know better than I which sub-issues should be an issue of their own.

Notes:

• The inconsistency occurs on Android 9 and 10. I can't currently test on Android 11+ devices.
• I'm mainly arguing pro consistency here.
• Only on a subordinate level, I'd regard "consistent key_down" as preferable over "consistent key_up", as the former is the natural way for physical keyboards to work. (*)

(*) Just imagine a piano producing sound on key up ... However, "up" events do make sense with touch input.

[GfEW]

It turns out that under some circumstances, some triggers do act on key_up. Even if that behavior could be considered consistent with the new key_up recording policy, it has really detrimental consequences.

Two particularly bad examples:

• I'm using Ctrl+Shift+v (all side/order variants) in termux to input Alt+Ctrl+Keycode_V, which pastes the clipboard, with Repeat until released enabled (to quickly insert a number of copies from elsewhere when needed, rather than from the kill ring). However in my recent configuration with expert mode on, that map reproducibly didn't input anything on Ctrl_down+Shift_down+v_down, but then upon v_up, suddenly spew out a series of however many copies it had accumulated internally in the meantime.
• Similar misbehavior with Ctrl+z/Ctrl+Shift+z for undo/redo, resp. - it didn't do anything on z_down, and then undid/redid an arbitrary number of steps at once on z_up.

These losses of input control, and deviations from expected behavior, amount to major usability disruptions. I've yet to determine the exact factors that make them occur or vanish, but for the time being, it's just a relief I've been able to stop them and get back to key_down (apparently) by disabling expert mode (still in v4.0.5-foss 247).

[jambl3r]

However in my recent configuration with expert mode on, that map reproducibly didn't input anything on Ctrl_down+Shift_down+v_down, but then upon v_up, suddenly spew out a series of however many copies it had accumulated internally in the meantime.

This is a new bug? Could you make a new issue for this one please

[GfEW]

I think it's relevant because it corrects context given further up:

• (1) triggering acts on "down" events

• (2) Only on a subordinate level , I'd regard "consistent key_down" as preferable over "consistent key_up"

The "build-up til key_up" behavior (now #2094) encountered in the termux and undo/redo examples above contradicts both (1) and (2).

It suggests that key_down everywhere (except touch input) should be regarded as important on its own, separately from the question of consistency ("up -> up" or "down -> down") between recording and retyping.