search

iberianpig / fusuma-plugin-keypress

Keypress combination plugin for Fusuma
https://github.com/iberianpig/fusuma#available-plugins
MIT License
26 stars 4 forks source link

Separate threshold/interval for keypress commands #3

Open ls-1N opened 4 years ago

ls-1N commented 4 years ago

It would be nice extra feature to be able to adjust the threshold and interval separately for each of the keypress commands.

So that e.g. without keypress you use one set of interval and threshold and for keypress LEFTCTRL you use another set of interval and threshold and another one for LEFTMETA.

Hoped this would work like that:

swipe:
  3:
    right:
      command: "xdotool click 9" # History forward
      keypress:
        LEFTCTRL:
         command: "xdotool key --clearmodifiers XF86AudioRaiseVolume"
         interval: 0.1
         threshold: 0.1
    left:
      command: "xdotool click 8" # History back
      keypress:
        LEFTCTRL:
          command: "xdotool key --clearmodifiers XF86AudioLowerVolume"
          interval: 0.1
          threshold: 0.1

Actually interval/threshold only work if I move them to the same indentation level as keypress, in which case they also apply to the history back and history forwards (which is unwanted in this case).

iberianpig commented 4 years ago

Thanks for your suggestion!

Here's what I'm thinking right now about adding features in the future.

I will not change the syntax of threshold/interval for swipe because we want to be compatible. Instead, we implement the following two

  1. Create a "3 or 4 finger ScrollDetector" for detecting scroll. This is different from the existing "Swipe", which publishes high-frequency real-time events rather than one shot.

  2. Create a ThrottleExecutor to upgrade an existing Executor ("command", "sendkey", etc.). It's a mechanism to reduce high-frequency events at a constant rate. Inspired by the lodash. https://lodash.com/docs/4.17.15#throttle

swipe:
  3: 
   left:
     command: echo "oneshot event"

scroll: # for realtime event
  3: 
   left:
     command: echo "realtime(100 events/sec)"
     throttle:
       wait: 100
       command: echo "event(10 events/sec)"
ls-1N commented 4 years ago

I'm sorry I think I'm not understanding completely. I meant my suggestion as an addition. So no existing feature would be changed. Just more granular controls for threshold and interval. So instead of current example of priorities from README:

  1. child elements in the direction (left/right/down/up → threshold/interval)
  2. root child elements (threshold/interval → swipe/pinch)
  3. default value (= 1)

It would be:

  1. keypress direction (because it is a child of directions in config)
  2. child elements in the direction (left/right/down/up → threshold/interval)
  3. root child elements (threshold/interval → swipe/pinch)
  4. default value (= 1)

To me it made visual sense. That said, part of the reason for writing this now is that I am not educated enough to understand your suggestion. (But I don't need to understand. I trust that you know what you're doing, so no need to waste your time on explanations, unless you want to).

Also I wanted to mention, that (even though I barely know anything about architecture) I think there is such a thing as overdoing backwards compatibility. I found using Fastlane really unpleasant because of all the legacy weirdness in it. Very little consistency and poor naming and things awkwardly glued onto other things all around. But nobody wants to break anything - even thought that's what major releases are for in semver. Not saying there's a problem here, but just something to keep in mind maybe.

iberianpig commented 4 years ago

I'm sorry for not being able to explain it well. I could understand that your idea is adding interval/threshold to "keypress".

I found using Fastlane really unpleasant because of all the legacy weirdness in it.

Is it https://github.com/fastlane/fastlane? I have never used it.

there is such a thing as overdoing backwards compatibility

Does it mean following ?

My English is not that good. But I want to write better software, so I want to understand what you're saying.

ls-1N commented 4 years ago

Does it mean following ?

* Fastlane users didn't like legacy syntax overdoing backwards compatibility

* they wanted upgrading syntax than keeping compatibility

I don't know much about common/popular opinion about fastlane. I only have my personal subjective uneducated opinion. With the sentence...

there is such a thing as overdoing backwards compatibility

... I meant that - I think a situation can exist in which other aspects of software are neglected horribly in order to remain backwards compatible. I mean other aspect like:

iberianpig commented 4 years ago

Thank you for your advice. I would like to make sure I don't lose the "simplicity" for the sake of "backward compatibility." I continuously improve Fusuma's interface to make it simple and easy to understand for new people.

ls-1N commented 4 years ago

Thanks for your lovely software.

iberianpig commented 3 years ago

BTW, Fusuma v2 has been released. https://github.com/iberianpig/fusuma/pull/224

  1. We've separated the gestures that are triggered frequently in real-time from the ones that are triggered in a single shot as before.
  2. You can configure global gestures and application-specific gestures separately. Check out fusuma-plugin-appmatcher.

These features should cover your use case.

swipe:
  3:
    right:
      update:
        keypress:
          LEFTCTRL:
            command: "xdotool key --clearmodifiers XF86AudioRaiseVolume"
    left:
      update:
        keypress:
          LEFTCTRL:
            command: "xdotool key --clearmodifiers XF86AudioLowerVolume"

---
context:
  application: Google-chrome

swipe:
  3:
    right:
      command: "xdotool click 9" # History forward
    left:
      command: "xdotool click 8" # History back