(G)rab, (R)otate, and (S)cale layers with hotkeys

[0HyperCube]

Closes #317

• Add new handler
• Add (neat) bindings to input mapper
• Handle translation mouse movement
• Handle rotation mouse movement
• Handle scale mouse movement
• Handle constrain to axis
• Handle number typing
• Handle shift to slow mouse movements
• Handle ctrl to snap rotation and scale
• Fix 0 scale breaking things
• Fix deselecting layers sometimes causing panic (trouble reproducing)

---

This change is 

[cloudflare-pages]

Deploying with    Cloudflare Pages

Latest commit:	1a2fec6
Status:	✅  Deploy successful!
Preview URL:	https://f2eba157.graphite-master.pages.dev

View logs

[Keavon]

I just played with the branch and this is super awesome! I really wish other tools like Illustrator had this functionality. This will be popular for sure.

[TrueDoctor]

Btw, just wanted to mention that I appreciate this work a lot. I will help to keep things organized so thanks!

[Keavon]

Fix deselecting layers sometimes causing panic (trouble reproducing)
I noticed the same thing, but didn't have time to try reproducing. If you get stuck on this, I can lend some time tomorrow trying to pin it down.

[Keavon]

Some UX observations/requests:

• If the user aborts (Esc/right click), it should return to the original transform even if the user successively hit G, R, and S to switch between modes)
• Please make it so the minus key toggles between positive and negative numbers that the user types. So they might type -1 to scale by negative 1, or -.5- to scale by positive 0.5. If only a minus key is pressed, but no numbers entered, nothing should happen yet and the mouse should still have normal control over it.
• Multiple presses of the decimal point key should only count the first one, and discard subsequent ones, as far as Backspace is concerned. Currently if you type numbers and decimal points together, it will delete the decimal point and cause no visible change (since it's not the first decimal point) but it should instead delete the next number from the sequence. The minus key should also not affect the backspace key at all, it minus should just toggle signs but not be part of the queue. You might want the very last backspace (when the list of values is empty) to reset the sign back to positive, though, to avoid confusing users who accidentally hit minus and can't figure out why they are stuck with negative numbers.
• While in number entry mode, I wonder if there's a way to block all other keyboard input (so you can't, for example change tools)?

[0HyperCube]

While in number entry mode, I wonder if there's a way to block all other keyboard input (so you can't, for example change tools)?

@Keavon You'd probably have to refer to @TrueDoctor but my guess is that this would not be trivial.

[TrueDoctor]

While in number entry mode, I wonder if there's a way to block all other keyboard input (so you can't, for example change tools)?

@Keavon You'd probably have to refer to @TrueDoctor but my guess is that this would not be trivial.

Should be pretty easy, just add a InputMapper::MaskEvents message

[Keavon]

If the user aborts (Esc/right click), it should return to the original transform even if the user successively hit G, R, and S to switch between modes)

@Keavon That is somewhat difficult with the current architecture. Looking at blender, if you are translating and then you rotate, the translate is reverted. Would this be acceptable behaviour?

Sure, that would be equally acceptable.

[Keavon]

Bug: when snapping a rotation, it doesn't let me snap back to the starting rotation (it skips that 15 degree increment, you can't go to 0 degrees, only the +15 or -15 surrounding it). Same deal for scale snapping: I can't snap to 1.0, only 0.9 or 1.1.

[0HyperCube]

Bug: when snapping a rotation, it doesn't let me snap back to the starting rotation (it skips that 15 degree increment, you can't go to 0 degrees, only the +15 or -15 surrounding it). Same deal for scale snapping: I can't snap to 1.0, only 0.9 or 1.1.

Fixed

[0HyperCube]

If the user aborts (Esc/right click), it should return to the original transform even if the user successively hit G, R, and S to switch between modes)

@Keavon That is somewhat difficult with the current architecture. Looking at blender, if you are translating and then you rotate, the translate is reverted. Would this be acceptable behaviour?

Sure, that would be equally acceptable.

Done

[0HyperCube]

Should be pretty easy, just add a InputMapper::MaskEvents message

@TrueDoctor What trigger should be used and how should it know only to advertise if the layer is being transformed?

[TrueDoctor]

Should be pretty easy, just add a InputMapper::MaskEvents message

@TrueDoctor What trigger should be used and how should it know only to advertise if the layer is being transformed?

So do you want to mask all keyboard input?
That would be something like:

(Ready, StartDragging) => {
  responses.push_back(InputMapperMessage::MaskKeyboardInputs)
  …
  }
  (Dragging, StopDragging) => {
    responses.push_back(InputMapperMessage::UnmaskKeyboardInputs)
  }

[0HyperCube]

@TrueDoctor It would still need typing numbers, x and y to constrain axis etc, this was why I believed it to be non trivial.

[TrueDoctor]

@0HyperCube @Keavon suggested adding different "input modes" that you could define. Like separate mapping definition files that you could switch between, but I don't know what the best approach for that would be.
You can think about a better solution I would need a bit of time and thought to come up with a better one

[0HyperCube]

@Keavon Are you fine without it for this for this PR?

[Keavon]

I'm happy with the features and UX. We can save input mode switching for another PR. I still want to review this for code quality though. I'll try to do that in an hour or two.

[Keavon]

@TrueDoctor what are your thoughts on having the unreachable!() branch arms and the places where unwrap() is used?