Skip to content

Replace time-acceleration with modifier-key granularity for arrow mov…#421

Open
IoannisNezis wants to merge 2 commits intoPattern-Projector:betafrom
IoannisNezis:arrow-key-granularity
Open

Replace time-acceleration with modifier-key granularity for arrow mov…#421
IoannisNezis wants to merge 2 commits intoPattern-Projector:betafrom
IoannisNezis:arrow-key-granularity

Conversation

@IoannisNezis
Copy link
Copy Markdown

Hey @courtneypattison,

my mom discrovered your amazing software and is a huge fan.
It saves her so much time and pain! Its extremely usefull.

I was delighted to see that this is a opensource project that's freely available.
I'm a software engineer myself and want to contribute to your project.

There a few things i noticed and would like to improve.
Starting with this one:

Pull Request Checklist

  • I have run yarn build to ensure that the project builds successfully.
  • I have updated CHANGELOG.md with the necessary changes made in this pull request.
  • I have added documentation for any new functionality from this pull request.

Description

Arrow key movement: modifier-based granularity + diagonal support

demo.mp4

What changed

Replaces the time-acceleration approach (cycling through a pixel list the longer an arrow key is held) with explicit granularity levels controlled by modifier keys:

Keys Step size
Arrow 1 px
Shift + Arrow 10 px
Alt + Arrow 0.5 px
Ctrl + Arrow 0.1 px
Shift + Ctrl + Arrow 100 px
Shift + Alt + Arrow 0.05 px

Behaviour improvements

  • Seamless granularity switching - adding or removing a modifier key while holding an arrow key transitions immediately, without releasing and re-pressing the arrow key.
  • Diagonal movement - holding two arrow keys simultaneously moves on both axes at once.
  • No motion interruption on quick key switches - held keys are tracked as a set; the repeat interval is shared across all held arrows and only stops when all are released.

Implementation notes

Movement is driven by a self-managed setInterval (30 ms, after a 400 ms initial delay) rather than relying on browser keydown auto-repeat. This fixes the browser halting repeated keydown events when a modifier key is added while an arrow key is held. Modifier and arrow state are stored in refs so the interval callback always reads current values without restarting. Held-key state is cleared on deactivation to prevent ghost movement if the hook is toggled while keys are physically held.

…ement

The previous implementation cycled through a pixel list (accelerating
movement the longer an arrow key was held). This replaces it with
explicit granularity levels controlled by modifier keys:

  Normal            1 px
  Shift             10 px
  Alt               0.5 px
  Ctrl              0.1 px
  Shift + Ctrl      100 px
  Shift + Alt       0.05 px

Movement is driven by a self-managed interval rather than browser
keydown auto-repeat, which fixes the browser halting keydown events
when a modifier key is added while an arrow key is held. Granularity
switches seamlessly mid-hold. Held keys are tracked as a Set, enabling
diagonal movement and uninterrupted motion when switching directions.
@vercel
Copy link
Copy Markdown

vercel Bot commented Mar 27, 2026

@IoannisNezis is attempting to deploy a commit to the Courtney Pattison's projects Team on Vercel.

A member of the Team first needs to authorize it.

@courtneypattison
Copy link
Copy Markdown
Collaborator

@IoannisNezis Apologies for taking so long to respond.

I do like the idea of being able to change the granularity of movement. Even for moving the whole pattern when projecting. My only concern it that this PR would make the keyboard versus touchscreen experience diverge quite a bit. Right now the move tool is the main way for touchscreen users to fine tune the corners on the calibration grid and that uses the time-acceleration method. Do you have any ideas for how to make both experiences similar? Maybe have an option in the move tool to adjust granularity? I'm not sure how that would look though.

Thank you so much for your contribution!

@edwardhorsford
Copy link
Copy Markdown

In my fork of the project I've generally adopted fine movements as standard, with shift being 10x - which is what Adobe Illustrator and many other apps tend to do. I'm not sure it needs 6 levels of adjustment - 0.5mm and 5mm has been plenty for me.

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.

3 participants