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

Christophe Jolif cjolif at gmail.com
Tue Mar 8 07:09:20 EST 2011


Thanks for your answers. I actually tested the code and it seems to work
correctly with my touch interactions. However it breaks dojox.mobile
buttons.

This is because dojox.mobile is using dojo.connect that way:

dojo.connect(source, event, method) this does not comply to the signature
which is (obj, event, context, method, dontFix) _but_ this is working
because dojo.connect it dealing with that (check if 3rd parameter is a
function). Your "override" of dojo.connect is not doing this thus the issue.

That brings several other comments:
1/ shouldn't we "override" dojo._connect instead of dojo.connect to avoid
this kind of things keeping the benefice of the tricks in dojo.connect?
2/ to avoid any risk of breaking existing stuff (like here) I would tend to
not auto map by default and maybe  not register the  connect override if
there is not auto mapping?

Regards,
--
Christophe

On Sun, Mar 6, 2011 at 3:34 PM, Evan Huang <evanhuangwei at gmail.com> wrote:

> Thanks, Christophe, please see my comments inline.
>
> BTW, the source package was also uploaded to github at
> https://github.com/evanhw/touch
>
> 2011/3/5 Christophe Jolif <cjolif at gmail.com>:
> > Thanks Evan, looks like I will be able to start testing this with the
> > charting touch interaction I'm working.
>
> That's great, though it's still in an initial shape, we'll also start
> testing it with dijit/dojo.dnd, please let me know if there are any
> issues.
>
> >
> > A few very small comments:
> > - dojo.isIPhone is not testing for iPad user agent. I guess it should?
> > - shouldn't it be dojo.isIOS instead by the way as it covers all iOS
> > devices?
>
> Yep, agree, only got chance to test on iPhone/Andriod yet, but
> dojo.isIOS would be a better way.
>
> > - for your issue #2 having several gestures configuration for the same
> > gesture on the same page might be confusing for the user I guess?
>
> This was discussed in previous threads but it's still debatable -
> whether the customizable configs is useful, need to figure out if any
> practical senorita e.g.having two regions with different swiping
> speed...
>
> >
> > Regards,
> > --
> > Christophe
> >
> > On Fri, Mar 4, 2011 at 2:52 PM, Evan Huang <evanhuangwei at gmail.com>
> wrote:
> >>
> >> 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!
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110308/87dd6f91/attachment-0001.htm 


More information about the dojo-contributors mailing list