Page MenuHomePhabricator

Open, TODOPublic


class @beta Efl.Canvas.Gesture_Touch extends Efl.Object
      delta @const 
      distance @const 
      @property start_point 
      @property cur_point 
      @property cur_timestamp 
      @property multi_touch 
      @property state 
bu5hm4n created this task.Jan 7 2020, 12:38 AM
bu5hm4n triaged this task as TODO priority.

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.
zmike moved this task from Backlog to Evaluating on the efl: api board.Jan 30 2020, 10:16 AM

I think this is mostly resolved, though we need to review/prune the API now.

zmike added a comment.Feb 3 2020, 6:12 AM
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.

I agree with the API and with what you said about multi_touch & touch_points_count.
However, maybe @segfaultxavi can check out the names, i feel like we maybe want to rename cur to current, so its a bit more expressive. I am also not sure if it should be point_record or record_point.

It's true that we want to be as expressive as possible.

I guess it should be point_record, but we can make it less confusing using point_add, maybe?

zmike added a comment.Feb 7 2020, 7:13 AM

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...

zmike added a comment.Feb 7 2020, 8:56 AM

Okay, so we'll expand here.

With the patches applied, this looks very fine.