So the dojo/gesture has been refined based on previous comments,
though still working on wraping up the tests/doh and docs, would like
to get it out for more thoughts.

- Tracking ticket - http://bugs.dojotoolkit.org/ticket/13828
- Refined code for browsing - https://github.com/evanhw/touch/tree/master/dojo
- Patch - http://bugs.dojotoolkit.org/attachment/ticket/13828/%2313828.patch

The above initially finished version mainly includes following changes:
1.Registry is removed, and major content of dojo.gesture is moved to
dojo/gesture/Base as a parental class.
2.Used on.emit() to fire and bubble gesture events
3.Added dojo.touch.cancel handle so that we a gesture can be cancelled.
4.Changed swipe to keep firing events during touchmove, the previous
version is actually a flicker gesture(though we may add it back later)

Also due to the fact that it's still subject to possible changes, I
intend to move it to dojox marked as experimental so that we have a
safer way to try it out and finalize the design and API after 1.7

Any comments are appreciated!

--------------------------------------------------------------------------------------------------------------------------------

Also moving related ticket discusson here:

#13828: [CLA][PATCH] Refine dojo/gesture and dojo/gesture/*

Comment (by Evan):

Thanks, Bill,

Replying to [comment:4 bill]:
I checked it over a bit. Questions:
- Not sure what "defaultEvent" or "subEvents" attributes in
subclasses of gesture/Base is for? Maybe I'm missing something, but
they don't seem necessary. Likewise with init(), _events and _remove().
I'm just not seeing why you need an infrastructure more complicated than
dojo/touch uses.
"defaultEvent" and "subEvents" mainly to accommodate with the Object
event, e.g. since we have the following usage:
- on(node, dojo.gesture.tap, func);
- on(node, dojo.gesture.tap.hold, func);
- on(node, dojo.gesture.tap.doubletap, func);

doesn't that already indicate a main-sub relationship e.g tap.hold.

Also we can't provide
- on(node, dojo.gesture.taphold, func)
since that violates module return way.

Maybe we can have a simper list, but still in the form as e.g. ["tap",
"tap.hold", "tap.doubletap"] to be consistent with the Object event usage?

The logic is a bit complex than touch because unlike dojo.touch which is
simply listening to native events, besides gesture event, dojo.gesture
also needs to listen, process and dispatch
"press"|"move"|"release"(including remove them - user won't explicitly do
that).

- You are firing synthetic DOM events as a side effect when on() is
called for a node. Is the idea that an app would call {{{on(node,
gesture.swipe, function(){/*empty function*/})}}} and then instead setup
handlers on <body> via {{{on(dojo.body(), "swipe.end", ...)}}}? I don't
really see the value here.
No, that's a not provided usage. "swipe.end" is simply the event.type user
got from callback in
- on(node, gesture.swipe, function(event){})

- I expected the swipe module to return {move: ..., end: ...} hash
rather than being used as swipe (which is the move gesture) and swipe.end.
Although either way works.
Hmm, was just thinng dojo.gesture.swipe is more clean to use.

- I thought a swipe implied a short, fast gesture but it looks like
the swipe code will fire on any touch move, even a long slow one?
Yep, based on my new understanding, swipe is just what you do when swiping
the screen of iPad or iPhone, no matter fast or slow, the viewport will be
slides.
A faster one but only fired when touchend is a flicker.

- the {{{lang.getObject("gesture", true, dojo);}}} in gesture/Base seems unnecessary
- in tap.js there's a clearTimeout() inside a setTimeout() callback that is unnecessary.
Gonna have a check, thx!

- in the line {{{this.fire(e.target, {type: "tap.doubletap"});}}}, it
seems unusual to have an event type containing a dot; it's inconsistent
with the browser native event doubleclick (which is called "doubleclick",
not "click.doubleclick")
Yep, I have the similar concern, but here just want to be consistent
with Object events usage as:
- on(node, dojo.gesture.tap, func);
- on(node, dojo.gesture.tap.hold, func);
- on(node, dojo.gesture.tap.doubletap, func);

Of course we can directly fire "tap", "taphold", "doubletap" or "swipeend"
etc. if we don't worry about that.

Search Discussions

  • Evan Huang at Sep 6, 2011 at 9:29 am
    And also Bill's comments on the ticket, so that we can continue
    discussion based on that.

    #13828: [CLA][PATCH] Refine dojo/gesture and dojo/gesture/*

    Comment (by bill):

    I talked to Evan about this a long time offline, here's what I learned:

    '''1. DOMNode synthetic events'''

    Although gesture/Base calls on.emit(node, ...), generating synthetic
    events on the DOMNode with names like "tap.hold", these synthetic events
    are for internal use only, specifically to deal with bubbling. For
    example, they are used to make sure that in the second on() callback
    below, the callback only executes when dojo.stopEvent() is *not* called:

    {{{
    on(inner, dojo.gesture.tap.hold, function(e){
    console.log('inner is tap.hold');
    if(xyz) dojo.stopEvent(e);
    });

    on(outer, dojo.gesture.tap.hold, function(e){
    console.log('outer is tap.hold');
    });
    }}}

    In the case above, the native touchstart, touchmove etc. events from the
    inner node bubble to the outer node, but with an _locking attribute set.
    So, the outer handler ignores them. But when dojo.stopEvent() is not
    called, the "tap.hold" synthetic event also bubbles upwards.

    Apps are not meant to listen directly for an event with a string name of
    "tap.hold".


    '''2. reference counting'''

    Considering app code that does this:

    {{{
    handle1 = on(node, tap, ...)
    handle2 = on(node, tap, ...)
    handle3 = on(node, tap.hold, ...)
    handle4 = on(node, tap.doubletap, ...)
    }}}

    On the first (and only the first) call to on(node, tap or tap.hold or
    tap.doublehold), dojo/gesture/tap (via dojo/gesture/Base) will setup 4
    internal listeners for touchstart, touchmove, touchend, touchcancel.
    Essentially, it sets up node to publish tap, tap.hold, and tap.doubletap
    notifications. And then the first on() call and subsequent() on calls
    are merely setting up subscriptions listening for those published events.

    The internal touchstart, touchmove, touchend, and touchcancel listeners
    will be removed when handle1, handle2, handle3, and handle4 have all been
    removed.

    I would have preferred if each on() call above generated it's own private
    internal listeners for touchstart, touchmove, touchend, touchcancel.
    However, it seems like the current design is necessary for the bubbling
    described above in !#1. We need exactly one synthetic "tap" event to be
    propagated from the inner node, regardless of how many tap listeners have
    been registered to listen to tap.


    ----

    My remaining issue is with swipe vs. flick:

    Just looking at (for example) gmail on iphone, there's are two ways to
    scroll:
    - moving my finger slowly: scrolling starts when I start moving my
    finger, and stops as soon as I lift up my finger
    - scrolling by a quick flick action: scrolling starts when I start
    moving my finger, but continues after I remove my finger (slowing down and
    eventually stopping over time)

    I'm unclear how to do that with the current gestures. Is it possible?

    On Tue, Sep 6, 2011 at 9:24 PM, Evan Huang wrote:
    So the dojo/gesture has been refined based on previous comments,
    though still working on wraping up the tests/doh and docs, would like
    to get it out for more thoughts.

    - Tracking ticket - http://bugs.dojotoolkit.org/ticket/13828
    - Refined code for browsing - https://github.com/evanhw/touch/tree/master/dojo
    - Patch - http://bugs.dojotoolkit.org/attachment/ticket/13828/%2313828.patch

    The above initially finished version mainly includes following changes:
    1.Registry is removed, and major content of dojo.gesture is moved to
    dojo/gesture/Base as a parental class.
    2.Used on.emit() to fire and bubble gesture events
    3.Added dojo.touch.cancel handle so that we a gesture can be cancelled.
    4.Changed swipe to keep firing events during touchmove, the previous
    version is actually a flicker gesture(though we may add it back later)

    Also due to the fact that it's still subject to possible changes, I
    intend to move it to dojox marked as experimental so that we have a
    safer way to try it out and finalize the design and API after 1.7

    Any comments are appreciated!

    --------------------------------------------------------------------------------------------------------------------------------

    Also moving related ticket discusson here:

    #13828: [CLA][PATCH] Refine dojo/gesture and dojo/gesture/*

    Comment (by Evan):

    Thanks, Bill,

    Replying to [comment:4 bill]:
    I checked it over a bit. ? Questions:
    - Not sure what "defaultEvent" or "subEvents" attributes in
    subclasses of gesture/Base is for? ? ?Maybe I'm missing something, but
    they don't seem necessary. ? Likewise with init(), _events and _remove().
    I'm just not seeing why you need an infrastructure more complicated than
    dojo/touch uses.
    ?"defaultEvent" and "subEvents" mainly to accommodate with the Object
    ?event, e.g. since we have the following usage:
    ?- on(node, dojo.gesture.tap, func);
    ?- on(node, dojo.gesture.tap.hold, func);
    ?- on(node, dojo.gesture.tap.doubletap, func);

    doesn't that already indicate a main-sub relationship e.g tap.hold.

    Also we can't provide
    - on(node, dojo.gesture.taphold, func)
    since that violates module return way.

    Maybe we can have a simper list, but still in the form as e.g. ["tap",
    "tap.hold", "tap.doubletap"] to be consistent with the Object event usage?

    The logic is a bit complex than touch because unlike dojo.touch which is
    simply listening to native events, besides gesture event, dojo.gesture
    also needs to listen, process and dispatch
    "press"|"move"|"release"(including remove them - user won't explicitly do
    that).

    - You are firing synthetic DOM events as a side effect when on() is
    called for a node. ? Is the idea that an app would call {{{on(node,
    gesture.swipe, function(){/*empty function*/})}}} and then instead setup
    handlers on <body> via {{{on(dojo.body(), "swipe.end", ...)}}}? ? I don't
    really see the value here.
    No, that's a not provided usage. "swipe.end" is simply the event.type user
    got from callback in
    - on(node, gesture.swipe, function(event){})

    - I expected the swipe module to return {move: ..., end: ...} hash
    rather than being used as swipe (which is the move gesture) and swipe.end.
    Although either way works.
    Hmm, was just thinng dojo.gesture.swipe is more clean to use.


    ?> - I thought a swipe implied a short, fast gesture but it looks like
    ?> the swipe code will fire on any touch move, even a long slow one?
    ?> Yep, based on my new understanding, swipe is just what you do when swiping
    ?> the screen of iPad or iPhone, no matter fast or slow, the viewport will be
    ?> slides.

    A faster one but only fired when touchend is a flicker.

    - the {{{lang.getObject("gesture", true, dojo);}}} in gesture/Base seems unnecessary
    - in tap.js there's a clearTimeout() inside a setTimeout() callback that is unnecessary.
    Gonna have a check, thx!

    - in the line {{{this.fire(e.target, {type: "tap.doubletap"});}}}, it
    seems unusual to have an event type containing a dot; it's inconsistent
    with the browser native event doubleclick (which is called "doubleclick",
    not "click.doubleclick")
    Yep, I have the similar concern, but here just want to be consistent
    with Object events usage as:
    ?- on(node, dojo.gesture.tap, func);
    ?- on(node, dojo.gesture.tap.hold, func);
    ?- on(node, dojo.gesture.tap.doubletap, func);

    Of course we can directly fire "tap", "taphold", "doubletap" or "swipeend"
    etc. if we don't worry about that.
  • Evan Huang at Sep 6, 2011 at 9:44 am

    On Tue, Sep 6, 2011 at 9:29 PM, Evan Huang wrote:
    And also Bill's comments on the ticket, so that we can continue
    discussion based on that.

    #13828: [CLA][PATCH] Refine dojo/gesture and dojo/gesture/*

    Comment (by bill):
    .......
    ?My remaining issue is with swipe vs. flick:

    ?Just looking at (for example) gmail on iphone, there's are two ways to
    ?scroll:
    ?- moving my finger slowly: scrolling starts when I start moving my
    ?finger, and stops as soon as I lift up my finger ------------------ 1
    ?- scrolling by a quick flick action: scrolling starts when I start
    ?moving my finger, but continues after I remove my finger (slowing down and
    ?eventually stopping over time) --------------------- 2

    ?I'm unclear how to do that with the current gestures. ? Is it possible?
    My observation on iPad for #1 was when you lift up finger, the
    viewport will also be bounced to the correct position.

    So based on my understanding, #1 and #2 are actually the same, swipe
    events are kept being fired during finger move - except #2 are faster.

    So with the current swipe impl, the sequence of both #1 and #2 would be:
    1. press(touchstart) - start recoginizing
    2. move(touchmove)
    - "swipe" event kept being fired with {dx, dy, time} properties,
    - we can move the div based on {dx, dy, time} properties,
    3. release(touchcancel)
    - "swipe.end" event will be fired still with {dx, dy, time} properties,
    - so that we can bounce the div to the target position with animation

    Of course #2 happened much faster.

    Also my understand of the difference of flicker and swipe is flicker
    has a min distance and speed(time) limit, and never get fired unitl
    the figer is lift up(not sure if that's correct) - this is exactly
    what the previous swipe.js does before being refined.

    - Evan
  • Eduardo Abe at Sep 6, 2011 at 1:40 pm
    Hello,

    Perhaps I'm missing something, but I am not seeing much differences between
    an implementation using this new 'swipe' gesture and another relying solely
    on the normal touch events (press/move/release).

    As for 'flick' (the old swipe), I wouldn't use it to scroll the view, I
    would rather use it to display the 'archive' button similarly to what gmail
    has. One improvement for 'flick' would be to fire the gesture event with
    dx/dy.

    Thanks,
    Eduardo




    On Tue, Sep 6, 2011 at 10:44 AM, Evan Huang wrote:
    On Tue, Sep 6, 2011 at 9:29 PM, Evan Huang wrote:
    And also Bill's comments on the ticket, so that we can continue
    discussion based on that.

    #13828: [CLA][PATCH] Refine dojo/gesture and dojo/gesture/*

    Comment (by bill):
    .......
    My remaining issue is with swipe vs. flick:

    Just looking at (for example) gmail on iphone, there's are two ways to
    scroll:
    - moving my finger slowly: scrolling starts when I start moving my
    finger, and stops as soon as I lift up my finger ------------------ 1
    - scrolling by a quick flick action: scrolling starts when I start
    moving my finger, but continues after I remove my finger (slowing down and
    eventually stopping over time) --------------------- 2

    I'm unclear how to do that with the current gestures. Is it possible?
    My observation on iPad for #1 was when you lift up finger, the
    viewport will also be bounced to the correct position.

    So based on my understanding, #1 and #2 are actually the same, swipe
    events are kept being fired during finger move - except #2 are faster.

    So with the current swipe impl, the sequence of both #1 and #2 would be:
    1. press(touchstart) - start recoginizing
    2. move(touchmove)
    - "swipe" event kept being fired with {dx, dy, time} properties,
    - we can move the div based on {dx, dy, time} properties,
    3. release(touchcancel)
    - "swipe.end" event will be fired still with {dx, dy, time} properties,
    - so that we can bounce the div to the target position with animation

    Of course #2 happened much faster.

    Also my understand of the difference of flicker and swipe is flicker
    has a min distance and speed(time) limit, and never get fired unitl
    the figer is lift up(not sure if that's correct) - this is exactly
    what the previous swipe.js does before being refined.

    - Evan
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110906/5306c699/attachment.htm
  • Christophe Jolif at Sep 6, 2011 at 10:42 am
    Just to let you know that I tested the patch with dojox.charting use of
    gesture (i.e. only doubleTap) and it does not break it.
    On Tue, Sep 6, 2011 at 3:24 PM, Evan Huang wrote:

    So the dojo/gesture has been refined based on previous comments,
    though still working on wraping up the tests/doh and docs, would like
    to get it out for more thoughts.

    - Tracking ticket - http://bugs.dojotoolkit.org/ticket/13828
    - Refined code for browsing -
    https://github.com/evanhw/touch/tree/master/dojo
    - Patch -
    http://bugs.dojotoolkit.org/attachment/ticket/13828/%2313828.patch

    The above initially finished version mainly includes following changes:
    1.Registry is removed, and major content of dojo.gesture is moved to
    dojo/gesture/Base as a parental class.
    2.Used on.emit() to fire and bubble gesture events
    3.Added dojo.touch.cancel handle so that we a gesture can be cancelled.
    4.Changed swipe to keep firing events during touchmove, the previous
    version is actually a flicker gesture(though we may add it back later)

    Also due to the fact that it's still subject to possible changes, I
    intend to move it to dojox marked as experimental so that we have a
    safer way to try it out and finalize the design and API after 1.7

    Any comments are appreciated!


    --------------------------------------------------------------------------------------------------------------------------------

    Also moving related ticket discusson here:

    #13828: [CLA][PATCH] Refine dojo/gesture and dojo/gesture/*

    Comment (by Evan):

    Thanks, Bill,

    Replying to [comment:4 bill]:
    I checked it over a bit. Questions:
    - Not sure what "defaultEvent" or "subEvents" attributes in
    subclasses of gesture/Base is for? Maybe I'm missing something, but
    they don't seem necessary. Likewise with init(), _events and _remove().
    I'm just not seeing why you need an infrastructure more complicated than
    dojo/touch uses.
    "defaultEvent" and "subEvents" mainly to accommodate with the Object
    event, e.g. since we have the following usage:
    - on(node, dojo.gesture.tap, func);
    - on(node, dojo.gesture.tap.hold, func);
    - on(node, dojo.gesture.tap.doubletap, func);

    doesn't that already indicate a main-sub relationship e.g tap.hold.

    Also we can't provide
    - on(node, dojo.gesture.taphold, func)
    since that violates module return way.

    Maybe we can have a simper list, but still in the form as e.g. ["tap",
    "tap.hold", "tap.doubletap"] to be consistent with the Object event usage?

    The logic is a bit complex than touch because unlike dojo.touch which is
    simply listening to native events, besides gesture event, dojo.gesture
    also needs to listen, process and dispatch
    "press"|"move"|"release"(including remove them - user won't explicitly do
    that).

    - You are firing synthetic DOM events as a side effect when on() is
    called for a node. Is the idea that an app would call {{{on(node,
    gesture.swipe, function(){/*empty function*/})}}} and then instead setup
    handlers on <body> via {{{on(dojo.body(), "swipe.end", ...)}}}? I don't
    really see the value here.
    No, that's a not provided usage. "swipe.end" is simply the event.type user
    got from callback in
    - on(node, gesture.swipe, function(event){})

    - I expected the swipe module to return {move: ..., end: ...} hash
    rather than being used as swipe (which is the move gesture) and
    swipe.end.
    Although either way works.
    Hmm, was just thinng dojo.gesture.swipe is more clean to use.

    - I thought a swipe implied a short, fast gesture but it looks like
    the swipe code will fire on any touch move, even a long slow one?
    Yep, based on my new understanding, swipe is just what you do when swiping
    the screen of iPad or iPhone, no matter fast or slow, the viewport will be
    slides.
    A faster one but only fired when touchend is a flicker.

    - the {{{lang.getObject("gesture", true, dojo);}}} in gesture/Base seems
    unnecessary
    - in tap.js there's a clearTimeout() inside a setTimeout() callback that
    is unnecessary.

    Gonna have a check, thx!

    - in the line {{{this.fire(e.target, {type: "tap.doubletap"});}}}, it
    seems unusual to have an event type containing a dot; it's inconsistent
    with the browser native event doubleclick (which is called "doubleclick",
    not "click.doubleclick")
    Yep, I have the similar concern, but here just want to be consistent
    with Object events usage as:
    - on(node, dojo.gesture.tap, func);
    - on(node, dojo.gesture.tap.hold, func);
    - on(node, dojo.gesture.tap.doubletap, func);

    Of course we can directly fire "tap", "taphold", "doubletap" or "swipeend"
    etc. if we don't worry about that.
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


    --
    Christophe
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110906/23eace5f/attachment.htm
  • Evan Huang at Sep 6, 2011 at 11:05 am
    Thanks, Christophe,

    Glad to know that though I haven't finished all tests.

    2011/9/6 Christophe Jolif <cjolif at gmail.com>:
    Just to let you know that I tested the patch with dojox.charting use of
    gesture (i.e. only doubleTap) and it does not break it.
    On Tue, Sep 6, 2011 at 3:24 PM, Evan Huang wrote:

    So the dojo/gesture has been refined based on previous comments,
    though still working on wraping up the tests/doh and docs, would like
    to get it out for more thoughts.

    - Tracking ticket - http://bugs.dojotoolkit.org/ticket/13828
    - Refined code for browsing -
    https://github.com/evanhw/touch/tree/master/dojo
    - Patch -
    http://bugs.dojotoolkit.org/attachment/ticket/13828/%2313828.patch

    The above initially finished version mainly includes following changes:
    1.Registry is removed, and major content of dojo.gesture is moved to
    dojo/gesture/Base as a parental class.
    2.Used on.emit() to fire and bubble gesture events
    3.Added dojo.touch.cancel handle so that we a gesture can be cancelled.
    4.Changed swipe to keep firing events during touchmove, the previous
    version is actually a flicker gesture(though we may add it back later)

    Also due to the fact that it's still subject to possible changes, I
    intend to move it to dojox marked as experimental so that we have a
    safer way to try it out and finalize the design and API after 1.7

    Any comments are appreciated!


    --------------------------------------------------------------------------------------------------------------------------------

    Also moving related ticket discusson here:

    #13828: [CLA][PATCH] Refine dojo/gesture and dojo/gesture/*

    Comment (by Evan):

    Thanks, Bill,

    Replying to [comment:4 bill]:
    I checked it over a bit. ? Questions:
    - Not sure what "defaultEvent" or "subEvents" attributes in
    subclasses of gesture/Base is for? ? ?Maybe I'm missing something, but
    they don't seem necessary. ? Likewise with init(), _events and
    _remove().
    I'm just not seeing why you need an infrastructure more complicated than
    dojo/touch uses.
    ?"defaultEvent" and "subEvents" mainly to accommodate with the Object
    ?event, e.g. since we have the following usage:
    ?- on(node, dojo.gesture.tap, func);
    ?- on(node, dojo.gesture.tap.hold, func);
    ?- on(node, dojo.gesture.tap.doubletap, func);

    doesn't that already indicate a main-sub relationship e.g tap.hold.

    Also we can't provide
    - on(node, dojo.gesture.taphold, func)
    since that violates module return way.

    Maybe we can have a simper list, but still in the form as e.g. ["tap",
    "tap.hold", "tap.doubletap"] to be consistent with the Object event usage?

    The logic is a bit complex than touch because unlike dojo.touch which is
    simply listening to native events, besides gesture event, dojo.gesture
    also needs to listen, process and dispatch
    "press"|"move"|"release"(including remove them - user won't explicitly do
    that).

    - You are firing synthetic DOM events as a side effect when on() is
    called for a node. ? Is the idea that an app would call {{{on(node,
    gesture.swipe, function(){/*empty function*/})}}} and then instead setup
    handlers on <body> via {{{on(dojo.body(), "swipe.end", ...)}}}? ? I
    don't
    really see the value here.
    No, that's a not provided usage. "swipe.end" is simply the event.type user
    got from callback in
    - on(node, gesture.swipe, function(event){})

    - I expected the swipe module to return {move: ..., end: ...} hash
    rather than being used as swipe (which is the move gesture) and
    swipe.end.
    Although either way works.
    Hmm, was just thinng dojo.gesture.swipe is more clean to use.


    ?> - I thought a swipe implied a short, fast gesture but it looks like
    ?> the swipe code will fire on any touch move, even a long slow one?
    ?> Yep, based on my new understanding, swipe is just what you do when
    swiping
    ?> the screen of iPad or iPhone, no matter fast or slow, the viewport will
    be
    ?> slides.

    A faster one but only fired when touchend is a flicker.

    - the {{{lang.getObject("gesture", true, dojo);}}} in gesture/Base seems
    unnecessary
    - in tap.js there's a clearTimeout() inside a setTimeout() callback that
    is unnecessary.
    Gonna have a check, thx!

    - in the line {{{this.fire(e.target, {type: "tap.doubletap"});}}}, it
    seems unusual to have an event type containing a dot; it's inconsistent
    with the browser native event doubleclick (which is called
    "doubleclick",
    not "click.doubleclick")
    Yep, I have the similar concern, but here just want to be consistent
    with Object events usage as:
    ?- on(node, dojo.gesture.tap, func);
    ?- on(node, dojo.gesture.tap.hold, func);
    ?- on(node, dojo.gesture.tap.doubletap, func);

    Of course we can directly fire "tap", "taphold", "doubletap" or "swipeend"
    etc. if we don't worry about that.
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


    --
    Christophe

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedSep 6, '11 at 9:24a
activeSep 6, '11 at 1:40p
posts6
users3
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase