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

Evan Huang evanhuangwei at gmail.com
Tue Mar 8 09:21:12 EST 2011


Thanks Emmanuel,

My understanding is since the native onmousexxx and ontouchxxx are
always both fired simultaneously(on iPhone & Andriod at least?), in
most cases we only need to listen to either one of them. That being
said, with dojo.touch, there is no need to add any new logic e.g.
dojo.connect(node, ''touchxxx,  callback) to existing dijit widgets,
dnd, charting or gauge etc. - instead things are done centrally in
dojo.touch. So auto mapping should be effective by default.

Turning off auto mapping is only useful in devices(BB tablet?) that
natively isolates mouse and touch events - where they are not fired
simultaneously. So we may want to bind two different callbacks for
mousedown and touchstart. To support this specific reqt in a more
flexible way, two possible ways we may try:

1. Add one more parameter like: dojo.connect = function(obj, event,
context, method, dontFix, noTouchMapping);
    - But this affects the dojo.connect() interface and makes
parameter list even longer

2. Or another alternative is checking obj['noTouchMapping'] within
dojo.connect()

We can try if any better options.

- Evan

On Mon, Mar 7, 2011 at 6:57 PM, Emmanuel Tissandier
<etissandier at gmail.com> wrote:
>
> 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
>> >
>> >
>> > On Wed, Jan 19, 2011 at 10:14 PM, Evan Huang <evanhuangwei at gmail.com>
>> > wrote:
>> >> Thanks, Bill,
>> >>
>> >> Please see my comments inline.
>> >>
>> >> 2011/1/19 Bill Keese <bill at dojotoolkit.org>:
>> >>> Cool, glad you are working on this.   FYI, I checked in support for
>> >>> drag-move a week or two ago, same changes as in your patch (although
>> >>> that's
>> >>> not the main part of your patch).
>> >>> Seems like the main idea of your patch is that the user does:
>> >>>    dojo.connect(node, "start"/"move"/"end", func)
>> >>> and it connects to either touch/mouse as appropriate, massaging the
>> >>> event
>> >>> object into a normalized form.   Is that right?    It makes sense. I'm
>> >>
>> >> Yep, the idea of the touch event layer is to:
>> >> 1. Make the same code(event related) run well both on mobile and
>> >> desktop
>> >>   - The suggested way is using dojo.connect(node,
>> >> "start"/"move"/"end", func), so user don't need to care about which
>> >> native events are used
>> >>   - If a user still chooses the native onmousexx/ontouchxx, and also
>> >> since we want to be compatible with existing dojo.dnd and dijit
>> >> widgets, the layer also does the auto mapping work(e.g. from
>> >> onmousexx/onMousexx to ontouchxx on mobile), so these code(e.g.
>> >> dojo.dnd, dijit) can still run well both on mobile and desktops
>> >>
>> >> 2. Recognize various gestures and provide unified gesture events(e.g.
>> >> onRotate) both on mobile and desktops
>> >>
>> >>
>> >>
>> >>> unclear what all those classes are for though, and if the user needs
>> >>> to know about them.
>> >>
>> >> There is an abstract Gesture class and we can inherit it for a certain
>> >> gesture, so we may have separate gesture classes for Rotate, Tap,
>> >> Flick etc. Instead of hard coding various recognizing logic in a
>> >> single class, this way shall provide better flexibility and ease for
>> >> customization. We can provide a set of default gestures each supports
>> >> corresponding gesture events, so user don't need to know about them,
>> >> they can simply do dojo.connect(node, "onRotate", func), except they
>> >> want to add a new gesture.
>> >>
>> >>
>> >>
>> >>> The other thing is that some blackberrys have both mouse and touch, as
>> >>> do
>> >>> some high end desktops machines
>> >>> (http://www.hp.com/united-states/campaigns/touchsmart/) so I think
>> >>> it's
>> >>> safer/easier to just connect to both touch and mouse events in all
>> >>> cases.
>> >>
>> >> Haven't got a chance to try blackberry, I think we still need more
>> >> testing for this, connecting both mouse and touch might be a problem
>> >> on iPhone since both native mouse/touch will be fired which then
>> >> causes double invoking on callback by default.
>> >>
>> >>
>> >>>   If we do need to branch based on whether the device is touch enabled
>> >>> or
>> >>> not, should be able to do a feature detection (just google for "touch
>> >>> event
>> >>> detection") rather than testing for iPhone/Android.
>> >>
>> >> Agree, will have a further look at this.
>> >>
>> >>
>> >>> PS:
>> >>> 1) the patch is a strange format, it doesn't list dijit/ or dojox/ or
>> >>> dojo/
>> >>> in the file names so it's hard to tell what goes where
>> >>> 2) the images in your design&impl doc don't show up for me (they are
>> >>> just
>> >>> blank)
>> >>> 3) couldn't see the video on mac but played on windows, nice to see
>> >>> all of
>> >>> you
>> >>
>> >> 1). Not sure why, but I've breakdown the patch into three pieces,
>> >> please apply them to dijit, dojo and dojox separately
>> >> 2). Seems it's due to some weird issue of drawing in the google doc,
>> >> should be working now.
>> >>
>> >>
>> >>> On Wed, Jan 19, 2011 at 12:02 AM, Evan Huang <evanhuangwei at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> So regarding the mobile touch event layer we discussed around DDD
>> >>>> last
>> >>>> year, we've got some initial progress - a detailed impl design +
>> >>>> prototype, would like to get it reviewed with everybody see if this
>> >>>> would be the right way to go or there is any parallel threads to
>> >>>> leverage?
>> >>>>
>> >>>> 1. Design & impl doc -
>> >>>>
>> >>>>
>> >>>> https://docs.google.com/document/pub?id=1OwgSJGNfh6jzAjHvagWj74wBxPmyiZBGishy5F96G48
>> >>>>
>> >>>> 2. Demo video - http://evan.dojotoolkit.org/touch/    - - demo.wmv
>> >>>>    - Prototyping the proposal by trying out Rotate and TapHod
>> >>>> gestures, also compatible with dojo.dnd and dijit.form.Slider)
>> >>>>
>> >>>> 3. Live demo (only tested on iPhone v.3GS) -
>> >>>> http://evan.dojotoolkit.org/touch/dojox/mobile/gesture/demo.html
>> >>>>
>> >>>> 4. Source code of the initial prototype -
>> >>>> http://bugs.dojotoolkit.org/attachment/ticket/12176/touch.patch
>> >>>>    - How to breakdown gesture events is a bit different from the
>> >>>> design doc, still in progress to figure out the best approach
>> >>>>
>> >>>>
>> >>>> Thanks!
>> >>>>
>> >>>> - Evan
>> >>>> _______________________________________________
>> >>>> dojo-contributors mailing list
>> >>>> dojo-contributors at mail.dojotoolkit.org
>> >>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> dojo-contributors mailing list
>> >>> dojo-contributors at mail.dojotoolkit.org
>> >>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>> >>>
>> >>>
>> >>
>> >
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>


More information about the dojo-contributors mailing list