Skip to content

actions: add directional - #85

Open
Owen271 wants to merge 1 commit into
InputActions:mainfrom
Owen271:directional
Open

Owen271 wants to merge 1 commit into
InputActions:mainfrom
Owen271:directional

Conversation

@Owen271

@Owen271 Owen271 commented Nov 11, 2026 •

Copy link
Copy Markdown

Navigating a grid-like UI, such as the window switcher or a grid of virtual desktops, with one continuous swipe isn't possible today: an interval repeats one action along one axis, and separate triggers per direction end or chain as soon as the swipe turns.

directional runs the action for a direction each time the motion along the dominant axis reaches distance. Each direction takes any action, initial runs on the first motion, and repeat_conditions stops further steps once the navigated UI has closed.

A matching wiki change is ready; I'll open it if this is accepted.

Converts two-axis motion into discrete actions, for navigating grid-like
UIs such as the window switcher with a single swipe. Every time the motion
along the dominant axis reaches the distance (default 75), the action for
that direction is executed. Reversing direction or switching axis restarts
accumulation, and at most 8 actions are executed per update.

Each direction takes any action, with its own conditions and limit. Input
actions among them enable the trigger's default modifier clearing. The
directional action must be the action of an update action without an
interval, so it cannot be in a group or have a limit. Updates without
motion are ignored until the first motion, since only swipe triggers
provide two-axis motion.

- initial: actions executed on the first update with motion, using the
  swipe angle, instead of waiting for the distance.
- repeat_conditions: checked on the main thread before executing each
  action. While not satisfied, motion is discarded. If satisfied on the
  first update with motion, the initial action is skipped.

Motion is processed on the main thread. Synchronous actions are
executed right after the repeat condition is checked, even if the action
thread is busy, so input cannot reach an application after the navigated
UI has closed. Asynchronous actions are scheduled on the action thread
instead of blocking the main thread. Motion queued behind a busy action
thread is posted to the main thread without blocking, so reloading the
configuration cannot deadlock.

Swipe triggers now pass their average angle to actions as
inputActionArgs.motionAngle.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant