All the inputs from the track pad are often confusing, and to my mind, not particularly useful.
I’m currently planning out a module that I think would make controls easier, and I am looking for feedback on it. Here’s the general concept (for trackpad control only, I’m ignoring multitouch, the normal buttons and physical movement of the control).
The only event is a key one, using ** buttonZ and buttonA.**
Why? Because relative touch events cannot physically happen without one of the two ‘buttons’ being pressed. Both axis and relative touch events would go, swallowed up by my controlling module.
This means I’m looking at generating my own phases / properties for the events you’d receive from my code, ie:
buttonA phases (trackpad hard press):
- Up
- Down
- Moved
buttonZ phases (light touch):
- Up
- Down
- Moved
- Cancelled (when a light touch becomes a buttonA down)
Up and down will include X and Y properties (ideally generated from the hardware at the moment of contact, but I’ll look into tying them into the relative touch event which would become hidden).
Cancelled is a special case for buttonZ only, when you lightly rest your finger starting a buttonZ event, but later press harder. This will generate a buttonZ cancelled event and a buttonA down event.
The moved event will have several new properties:
- _ .isSwipe - boolean. Has your finger moved enough from the last resting place for it to be considered a deliberate swipe movement, or is it either just movement noise or a minimal amount not worthy of treating seriously (think tiny movement on the home screen, enough to tilt the app icons, but not enough to select different apps). You can control the tolerance._
- _ .hasBeenSwiped - boolean. False if at no time this touch event had .isSwipe set to true._
- _ .direction - string. If isSwipe == true then it will return the direction the current movement since last resting place / corner is most aligned to. This could be up, upright, right, downright etc (8 possibilities - I don’t see any point in offering more than this as the controller is too small for more accurate representations, and even 8 might prove to be too many). If isSwipe == false then this returns none._
- _ .axisAlignedDirection - string. If isSwipe == true then like .direction it will return a string, but this time can only be up, right, down or left. Otherwise, none._
- _ .angle. Contains the actual angle from the last resting place / corner to the current touch position._
- _ .distance. Contains the distance from the last resting place / corner to the current touch position._
- _ .lines. Contains a table of all the different line segments generated during this single touch._
Now it should be noted the X and Y data will be presented in both absolute and relative values.
Also, the moved event would track line segments. You’d be able to specify the actual way these are calculated, including:
- Just a single line segment. startX and startY are always where the touch started, and values like .direction, .angle and .distance are always calculated based on this start point to the current touch location.
- Line segments start and end upon direction change (axis aligned).
- Line segments start and end upon direction change (8 directions).
- It might also be worthwhile being able to manually trigger a new line segment mid-touch.
For multi segment touches, it might be worthwhile to have the ability to either do it as mentioned above, or every time a new line segment is begun to trigger a buttonA / Z up and a fresh buttonA / Z down set of events (IE so each line segment is treated discretely). Will have to see how that goes in practice.
That seems to me to be pretty much everything that’s needed, and would tie in with the current properties nicely, as well as making the whole system more managable and sensible IMO.
Thoughts?