Open keithclark opened 4 years ago
Coverage summary | ||
---|---|---|
Statements | 28.93% | 2018/6976 |
Branches | 20.19% | 211/1045 |
Functions | 28.96% | 651/2248 |
Lines | 28.82% | 1951/6770 |
From Jenkins: kano-code/PR-1825
Hey Keith! This looks great, and we would be happy to accept this. At this point, we'd probably want to put it behind a communityParts
flag until we're sure its ready to be included in the parts library on Kano World.
How does the communityParts flag work? Would the part be accessible in the editor on Kano World once the flag is toggled on?
Is there anything extra you need from me to progress this?
[WIP] Prototype Joystick Part
This PR is a first stab at creating a Joystick input part for the Kano Code editor. It provides authors with a means to interact with their creations using a universal joystick input that responds to touch, mouse and keyboard.
Features
Sticks have a dead zone to prevent input noise when used with a mouse or touch. Once the handle has moved outside the dead zone the input is considered valid.
Sticks are dual axis (X/Y) but can be locked to a single axis, allowing authors to limit inputs to up/down or left/right.
Sticks expose boolean properties for up, down, left and right so authors can check state.
Sticks expose a direction property. This is useful when used with Sticker parts (used as sprites) as authors can orientate and move them based on the position of a stick. For keyboards, this is limited to 45 degree steps for dual axis configuration, or opposing 180 degree steps for single axis. For touch and mouse inputs there are 360 degrees of movement.
Sticks expose a force property. The value represents how far outside the dead zone a stick has moved. It ranges from
0
(stick is at rest) to1
(full movement). For keyboard input, force can only be0
or1
. For touch / mouse, force will vary with distance.Sticks can be positioned using the
moveTo
method, exposed byTransformAPI
.Multiple sticks can be added to a creation. This works well for touch devices and for keyboards with the two inputs are locked to different axis. It doesn't yet work with two 8-way sticks as they both respond to the same set of keys.
Sticks listen for touch, mouse and keyboard events. Touch and mouse wait for the user to trigger a touchstart/mousedown event on a stick. For keyboard, I originally added
tabIndex
to the preview/player and listened for key events on that. However, this meant authors had to give focus to the player before the sticks would work, which became frustrating to work with. To resolve this, I now listen for key events on thebody
element. To prevent unintended input while editing code, events are ignored if the author is focused on a form control while inside the block editor. This allows creation authors and viewers to control sticks without having to have the creation player capture input first.Screenshots
Toolbox additions
Add Part menu
Part List item
Editor
Examples:
This PR contains two examples to play with:
Todo:
getBoundingClientRect
with methods in "parts/dom/dom.js"Future refactoring notes