Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

An idea of simplifying track pad controls (via lua) - comments / feeback?
Started by rakoonic Jul 01 2016 10:22 AM

4 replies to this topic
[TOPIC CONTROLS]
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

rakoonic

[GLOBAL: userInfoPane.html]
rakoonic
  • Contributor

  • 112 posts
  • Corona SDK

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:

 

  1. .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.
  2. .hasBeenSwiped - boolean. False if at no time this touch event had .isSwipe set to true.
  3. .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.
  4. .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.
  5. .angle. Contains the actual angle from the last resting place / corner to the current touch position.
  6. .distance. Contains the distance from the last resting place / corner to the current touch position.
  7. .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:

 

  1. 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.
  2. Line segments start and end upon direction change (axis aligned).
  3. Line segments start and end upon direction change (8 directions).
  4. 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?



[TOPIC: post.html]
#2

rakoonic

[GLOBAL: userInfoPane.html]
rakoonic
  • Contributor

  • 112 posts
  • Corona SDK

Note for example if you only care about button presses, you just ignore the moved phases, or set specific event listeners for up and down.

Likewise if you only care about swipes, then just set up a specific moved event listener, and ignore any events that have the .isSwipe property set to false.

I believe I'd also send the various line segment values upon a button up event, so if you just want to read the result of a swipe once the finger is off the track pad, you can access all the data at the end from a single listener called just once.



[TOPIC: post.html]
#3

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 26,068 posts
  • Enterprise

From someone who's built an app for AppleTV that all seems reasonable.

 

Rob



[TOPIC: post.html]
#4

rakoonic

[GLOBAL: userInfoPane.html]
rakoonic
  • Contributor

  • 112 posts
  • Corona SDK

At the moment I just have 2 problems with it:

 

1 - Pressing the trackpad button doesn't give X and Y values (and it is possible to press the button without generating any relativetouch events)
2 - the .reportsAbsoluteDpadValues simply doesn't work.

Any idea if these are in line to be sorted some time soon?



[TOPIC: post.html]
#5

Rob Miracle

[GLOBAL: userInfoPane.html]
Rob Miracle
  • Moderator

  • 26,068 posts
  • Enterprise

I don't know if we have bug reports/feature requests filed on either of those. If the .reportsAbsoluteDpadValues doesn't work, we will need a bug report for this. Adding X, Y values to the button events would require a feature request at https://feedback.coronalabs.com.

 

Rob




[topic_controls]
[/topic_controls]