On Sat, 16 Jan 2010 21:13:25 -0200 Gustavo Sverzut Barbieri
<barbi...@profusion.mobi> said:
> I have no clue about multi touch and specially the low level reporting
> system, but what's good in this? I mean, there is no way to know
> number of touchs at that time. Okay, down-up are fine, since they
> might go at different time, but move should have a list of radius and
> positions, no?
while what you say makes sense for some uses, it does not for others. for
example - virtual kbd. when i am simply hitting multiple keys at once - i want
multiple press events, not 1 press event with multiple points. non-multi-touch
apps would become confused as they use the basic mouse down events which now
contain multi info. thats a lot of them. i moved "extra presses" to separate
event callbacks in evas so you wont have issues. yes - if you want do
"pinching" it becomes harder as u need to track 6 not 3 callbacks and thus
track the 2 points, but it means things don't break. as such xinput2 reports in
the only real-life case, mult-touch events as separtate events to core mouse
events (first finger). 2nd finger is an extra xi2 floating input device that
issues its own events separately.
> The way it is will make life hard to users, they will have to track
> and mix down-up events to know the big picture of how many fingers are
> there (it's just harder), but on move you're quite without relevant
> data.
and the other way makes life hard for all existing code... :)
> Again, I might be saying shit as I never saw low level reporting APIs
> and Xi2 (if related), but for development POV, this would be better:
>
> Multi_Touch_Base:
> unsigned int count;
> struct {
> int radius, radius_x, radius_y;
> Eina_Bool current; /* would flag activity in the event mode:
> down, up or move */
> struct {
> int x, y;
> } output;
> struct {
> Evas_Coord x, y;
> } canvas;
> } points[];
>
> Dow:
> <event-specific>
> Multi_Touch_Base common;
>
> Up:
> <event-specific>
> Multi_Touch_Base common;
>
> Move:
> <event-specific>
> Multi_Touch_Base cur, prev;
>
> Maybe this is even the way it is reported by the hardware, if not we
> can keep this state inside evas and avoid doing it in every app that
> wants to use multi-touch events. Some processing examples with these
> new structures:
makes sense - but has its own downsides as well.
> Double finger click:
> if (down->common.count == 2)
>
> Double finger click (considering some spacing):
> if ((down->common.count == 2) &&
> (abs(down->common.points[0].x - down->common.points[1].x) >
> THRESHOLD) &&
> (abs(down->common.points[0].y - down->common.points[1].y) >
> THRESHOLD))
>
> pinch (iphone zooming):
> if ((move->common.count == 2) &&
> ((down->cur.points[0].x - down->cur.points[1].x) >
> (down->prev.points[0].x - down->prev.points[1].x)) &&
> ((down->cur.points[0].y - down->cur.points[1].y) >
> (down->prev.points[0].y - down->prev.points[1].y)))
>
> of course most real things will need some history and path-fitting to
> smooth values and detect gestures and ignore errors from measurements
> (that can go into another lib)
to be honest - this kind of 'gesture' interpretation could well do with being a
library on top that will do this for you and just feed out gestures it sees as
more callbacks once it has interpreted the events on an object.
eg:
Egesture *egesture_add(Evas_Object *o);
void egesture_del(Egesture *eg);
void egesture_callback_add(Egesture *eg, Egesture_Type type, Egesture_Func
func, void *data);
etc.
where type is EGESTURE_TYPE_CLICK, DRAG, DOUBLE_CLICK,2_FINGER_CLICK, PINCH,
etc. etc.
the gesture handler can handle all the usual single-finger stuff as well as
multi-touch stuff and just call your callback once the gesture is recognised
(along with information on the input params - eg for pinch or drag).
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
