[dojo-contributors] Initial shape of dojo.touch + dojo.gesture

Evan Huang evanhuangwei at gmail.com
Wed Mar 9 01:37:42 EST 2011


Thanks, comments inline.

On Wed, Mar 9, 2011 at 8:56 AM, Eduardo Abe <eabe at us.ibm.com> wrote:
> Hello Evan,
>
> I have tried to use my GFX patch on top of your touch support and it works
> quite well, both for Canvas and SVG - but I was forced to modify my Canvas
> event model implementation because it was expecting 'onmousexxx' and your
> code is now firing 'mousexxx'. In other words, your code was not completely
> transparent to my implementation and that might happen to other components
> as well. For instance, the partial event support in GFX Canvas renderer will
> also have problems with that change. Let me know if you want to discuss
> that.

Actually dojo.touch is compatible with either way, just as existing
dojo.connect(), events are normalized first so both onmousexxx or
mousexxx should work well. I'll have a quick try then.


> One thing to be considered: the automatic mapping needs to take 'tap' into
> account, mapping a 'click' into a 'tap' and vice-versa otherwise the code
> relying on 'click' event will not work. And perhaps something related to
> popup menus as well (right-click mapped to taphold?)

Yes, let's address them in the next drop.


> Please see the remainder of my comments in "magenta" below.
>
> Thanks,
> Eduardo
>
>
>
>
> From:        Evan Huang <evanhuangwei at gmail.com>
> To:        Eduardo Abe/Sunnyvale/IBM at IBMUS
> Cc:        "dojo dev." <dojo-contributors at mail.dojotoolkit.org>, rqruanqi
> <rqruanqi at cn.ibm.com>, zhongsq <zhongsq at cn.ibm.com>, heguyi
> <heguyi at cn.ibm.com>
> Date:        03/08/2011 06:49 AM
> Subject:        Re: [dojo-contributors] Initial shape of dojo.touch +
> dojo.gesture
> ________________________________
>
>
> Thanks Eduardo,
>
> Please see my comments line.
>
> - Evan
>
> On Tue, Mar 8, 2011 at 4:36 PM, Eduardo Abe <eabe at us.ibm.com> wrote:
>> Hello Evan,
>>
>> Thank you for this preview, and sorry for the delay in responding - only
>> now
>> I had the chance to look into your code with more attention.
>> My feedback is similar to Emmanuel's, I believe that the auto-mapping
>> should
>> be configurable 'per component' as I can imagine scenarios where a mobile
>> application will combine 'touch-aware' components with regular
>> 'touch-unaware' ones.
>
> Yep, please see my comments on Emmanuel's thread
>
> Ok!
>
>
>> As expected, with the auto-mapping the touch-and-mouse-enabled components
>> will be notified twice.
>
> Well, in most cases we only need to listen to either one of them.
>
> True, I am currently not aware of any component doing both - other than my
> GFX patch ;)
>
>
>> On the other hand, I have noticed (at least on iPhone) that when the
>> auto-mapping is disabled the 'touchend' event will trigger the iPhone
>> default mapping (which is a 'mousemove'+'mousedown'+'mouseup'+'click') - I
>> wasn't expecting that.
>
> That's due to the native behavior(should be the same both in iPhone
> and Andriod) - ontouchxxx and onmousexxx are always being fired at the
> same time, so if we dojo.connect(n, 'mousexxx', callback), though auto
> mapping is not effective, the native onmousexxx still get fired, so I
> think the only way to break the sequence is dojo.stopEvent(e) in
> onmousexxx callback.
>
> Yes, a 'dojo.stopEvent(e)' is needed to prevent the default behavior and
> I am fine with that being documented somewhere. But I'm wondering if it
> wouldn't be nice to register a listener at the document level to do that
> whenever the automatic mapping is disabled? That would be transparent to
> the user.
>
>
>> I do have some remarks concerning your Tap gesture, I believe that the
>> 'tapholdcancel' and 'tapstart' are unnecessary. A 'taphold' gesture is
>> supposed to last about 800ms, it is just too quick and the great majority
>> of
>> users are only expecting in two notifications: 'tap' and 'taphold'.
>
> Agree, 'taphold' is simply cancelled by releasing touch before the
> holdthreshhold and not figured out any scenario we need to hook in
> something. There shouldn't be a 'tapstart' - the Tap impl was only for
> testing how the base dojo.touch/dojo.gesture work, it was simply
> reusing stuff in the previous demo.
>
> Great!!
>
>
>> In the quite unlikely case of the system firing a 'touchcancel' the screen
>> will become unresponsive and any 'tap' and 'taphold' gesture that might be
>> happening will fail, no listeners will ever know that the user was tap the
>> screen - which is the right thing to do.
>>
>> The same idea also applies for 'Swipe', the gesture should only fire
>> 'swipeUp', 'swipeLeft' (or whatever name we decide to call them).
>>
>>  I have a Tap and Swipe implementation that should do the trick, I'll port
>> hem to work with your code - that will cover all the basic gestures that
>> do
>> not rely on multi touch  ;-)
>
> Cool, looking forward to that :-)
>
> Sure, let's try to coordinate to have it available on your second drop.
>
>
>> Thanks,
>> Eduardo
>>
>>
>>
>>
>> From:        Emmanuel Tissandier <etissandier at gmail.com>
>> To:        "dojo dev." <dojo-contributors at mail.dojotoolkit.org>
>> Cc:        Evan Huang <evanhuangwei at gmail.com>, Eduardo
>> Abe/Sunnyvale/IBM at IBMUS, rqruanqi <rqruanqi at cn.ibm.com>, zhongsq
>> <zhongsq at cn.ibm.com>, "Emmanuel.Tissandier"
>> <Emmanuel.Tissandier at fr.ibm.com>
>> Date:        03/07/2011 03:00 AM
>> Subject:        Re: [dojo-contributors] Initial shape of dojo.touch +
>> dojo.gesture
>> ________________________________
>>
>>
>>
>> Thanks Evan for this initial drop, I have tested it with my work on Dojo
>> Gauges and it seems to work without requiring any changes on my side.
>> I have only one comment about the automatic mapping of mouse handlers to
>> touch events (dojo.touch.autoMapping). If a component has already
>> implemented a touch support as well as a mouse support, then,  with this
>> 'autoMapping' on , depending on the order of the dojo.connect, the touch
>> support implemented in the widget may be replaced by the mouse support,
>> which is not really what we want.
>> I know that this auto mapping can be turned off, but I would prefer that
>> this auto-mapping can be done per-component rather than globally.
>> For me the best solution would be to add the touch support to the
>> components
>> that require some touch interaction...
>>
>> Emmanuel
>>
>>
>> 2011/3/4 Evan Huang <evanhuangwei at gmail.com>
>> Hi Everyone,
>>
>> Regarding this thread, we've got an initial shape of dojo.touch +
>> dojo.gesture, still need more insights to ensure it's the right way to
>> go.
>>
>> Here is the v. 0.1 version -
>> http://bugs.dojotoolkit.org/attachment/ticket/12176/touch0.1.patch
>> p.s - we shall be reviewing the further versions in a more convenient
>> way once I finished setting up my github.
>>
>> The basic idea is simply intercepting dojo.connect both in
>> dojo.touch/dojo.gesture, and here are more details
>>
>> 1. dojo.touch - usage e.g. dojo.connect(node, 'touchstart |...',
>> callback);
>>
>> a. Auto mapping for onmouse* <---> ontouch*, so with this:
>>   - dijit and dojo.dnd shall work well on mobile without changing the
>> original event logic
>>   - Mobile widgets can also handle mouse events well when running on
>> desktop(since ontouch* will be automatically mapped to onmouse*)
>>   - Users can also turn this off by e.d. dojo.touch.autoMapping =
>> false, in that way, touch and mouse events are then isolated - this
>> might be useful for devices both supporting mouse and touch e.g.BB
>> tablet
>>
>> b. Very basic normalization works for the native touch events
>> (including "orientationchange" etc., more work to be done on this with
>> testing going on with more devices)
>>
>> c. Other events(besides the ontouch* | onmouse*...) will be simply
>> passed along to the original dojo.connect()
>>
>> -------------------------------
>>
>> 2. dojo.gesture (based on dojo.touch) - usage e.g. dojo.connect(node,
>> 'taphold |...', callback);
>>
>> a. Gesture registration
>> - Eeah gesture impl(e.g. Tap) will register itself when required via
>> dojo.gesture.add('new dojo.gestures.Tap()'); or if we finally choose
>> to only support singleton Gesture in the same page, we can then use a
>> simper way like dojo.gesture.add("Tap")
>>
>> b. Gesture listener managing
>> - We have a { } Obj wrapping target node and gesture callbacks - this
>> is is a similar way as wink does
>>
>> c. When native events(either ontouch* or onmouse*) triggered, we'll
>> invoke start() | move() | end() for gestures that are registered(by
>> dojo.connect()) on a given node
>>
>> d. Ideally in the future many single point gestures(e.g. tap, taphold,
>> swipe, press-n-drag) should work well both on desktop and mobile
>>
>> --------------------------------
>>
>> Not pretty much to see as a demo at this point except for the
>> test_touch.html/test_gesture.html in the patch(only tested on iPhone
>> 3, Andriod 2.1):
>> 1. test_touch.html
>>    - Showing  dojo.connect(node, "touchstart | mousedown |...",
>> callback); work well both on mobile/desktop
>> 2. test_gesture.html
>>    - Showing dojo.connect(node, "tap | taphold | tapholdcancel",
>> callback); work well both on mobile/desktop
>>
>>
>> [Open issues]
>> 1. Instead of using "start | move | end" as standarlized
>> events(mentioned in
>>
>> https://docs.google.com/document/pub?id=1OwgSJGNfh6jzAjHvagWj74wBxPmyiZBGishy5F96G48),
>> we are now following W3C touch spec(in draft -
>> http://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html)  though
>> it seems a bit iPhone prone
>>
>> 2. Whether need to support multiple Gesture instances in the same
>> page? So that we can have different gesture settings e.g. different
>> holdThreshold for two taphold gestures
>>
>> 3. Gesture bubbling & conflicts
>>
>> 4. More to come...
>>
>>
>> Thanks!
>>
>> - Evan
>>
>> On Thu, Jan 20, 2011 at 11:31 PM, Evan Huang <evanhuangwei at gmail.com>
>> wrote:
>>> In case anybody doesn't notice this,  here are some key points we
>>> covered during today's IRC on touch:
>>>
>>> 1. Split the touch stuff into two parts:
>>>    a. Touch base - manager + register + [ TBD - most common Tab
>>> related gestures ]   ---> put it under dojo, e.g. dojo/touch.js
>>>    b. A separate gesture package, e.g. dijit.gestures? - TBD
>>>
>>> 2. #a - the touch base should be kept independent so that we can reuse
>>> it across dijit/dojo/dojox
>>>
>>> 3. #b - various gestures can be required on demand(pluggable) through
>>> define()
>>>
>>> 4. User can add new customized gestures based on #a, #b
>>>
>>> 5. [open issue] - how to deal with collisions among gestures during
>>> recognizing?
>>>
>>> 6. [need double check] - onmouse/ontouch will be both fired?
>>>    [TBD] - auto-generate mouse events (or nt) for dijit e.g.
>>> ondijitclick -> ondijitdown?
>>>
>>> Thanks!
>>> - Evan


More information about the dojo-contributors mailing list