Accumulate bytes to extend rule processing

[rstanuwijaya]

In the current implementation, each notification rule is processed independently without a memory to allow for fine-tuned operations. For instance, adjusting the volume using the thumbwheel on the MX Master 2S mouse may result in excessively fast speed. To address this limitation, it would be beneficial to introduce a counter for byte sequences, enabling deferred actions once the counter surpasses a certain threshold.

A proposed configuration could look like this:

- Rule:
  - Feature: GESTURE 2
  - TestBytes: [3, 4, 1, 128]
  - AddCounter: ["thumbwheel_counter", testBytes_return_value_asSignedInteger]
- Rule:
  - Feature: GESTURE 2
  - TestBytes: [3, 4, -127, -1]
  - AddCounter: ["thumbwheel_counter", testBytes_return_value_asSignedInteger]
- Rule:
  - CheckCounter: ["thumbwheel_counter", "larger_or_equal", 5]
  - AddCounter: ["thumbwheel_counter", -5]
  - Execute: [echo, volup]
- Rule:
  - CheckCounter: ["thumbwheel_counter", "less_or_equal", -5]
  - AddCounter: ["thumbwheel_counter", 5]
  - Execute: [echo, voldown]

In this configuration, a counter is represented as a dictionary with a string key mapped to a signed integer value. The following basic operations can be performed:

1. SetCounter(key, val): Creates or resets a counter with the given value.
2. AddCounter(key, val): Creates a counter with a default value of 0 if the key doesn't exist. Otherwise, it adds the specified value to the current counter value.
3. CheckCounter(key, op, val): Performs arithmetic or bitwise operations on the counter based on the provided operator and value.

[pfps]

This does seem like a reasonable idea. Solaar already does something similar for the THUMB_WHEEL feature.

[pfps]

A problem with your rules is that if the thumb wheel message has a displacement of more than 10 only 5 will be used up immediately. The next notification may then use another 5, and so on.
I'm not sure how to best solve this problem.