class @beta Efl.Canvas.Gesture_Touch extends Efl.Object point_record delta @const distance @const @property start_point @property cur_point @property cur_timestamp @property multi_touch @property state }
From the API POV:
- In order to support multitouch, we should add a "tool :int" to every function except multi_touch and point_record. (A few already have them)
- we could change "multi_touch" from a boolean flag to a "number_of_active_fingers" (If a finger is removed, all indexes > X (that is removed) do shift by -1 we then have to internally remodel that somehow
- There is a hash used to store the different tools, we could probebly just use a inarray, thats way more efficient, we always have continues ID's
- The state EFL_GESTURE_TOUCH_END looks a bit buggy to me, there is no real support for multi touch with that i think.
class Efl.Canvas.Gesture_Touch ├ (P) start_point ├ (P) cur_point ├ (P) cur_timestamp ├ (P) multi_touch ├ (P) touch_points_count ├ (P) state ├ (P) cur_data ├ (P) prev_data ├ (M) point_record ├ (M) delta ├ (M) distance ├ (M) data_get
I'm thinking we can probably remove multi_touch since touch_points_count exists.
point_add doesn't really work since it also is used for updating the current state of an already-added touch point.
Do we really want to expand cur/prev? I think we use these in other places in the api don't we?
Besides yours, we have no other prev_ and one previous_, one cur_ and 6 current_. I'm pretty sure we are striving for explicitness everywhere else.
Regarding point_record, alright then. We can think about point_update too but I don't think there's much difference.
Just make sure the docs mention that this methods adds points as well as updates existing points...