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

Emmanuel Tissandier etissandier at gmail.com
Mon Mar 7 05:57:38 EST 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110307/ff39152d/attachment.htm 


More information about the dojo-contributors mailing list