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

Bill Keese bill at dojotoolkit.org
Wed Mar 9 16:37:05 EST 2011


OK, so an app explicitly requires dojo.touch if it needs mobile support... I
just don't like how including dojo.touch could affect/break "library" code
that the app includes.   By "library code" I mean any code written by
different people than than the app developers.

Also, I'm not keen on making apps explicitly require dojo.touch to get
mobile support, it seems like mobile should work out-of-the-box.  Opinions?

FWIW, I don't think there are too many changes required to existing code, I
actually already fixed DnD (drag-move) and dijit's Slider (mostly).   The
only other broken component that I know is BorderContainer.


On Thu, Mar 10, 2011 at 1:11 AM, Evan Huang <evanhuangwei at gmail.com> wrote:

> Hi Bill,
>
> My comments inline.
>
> - Evan
>
> On Wed, Mar 9, 2011 at 4:35 PM, Bill Keese <bill at dojotoolkit.org> wrote:
> > I'm uneasy about the automatic mapping from onmouse* to ontouch*.   Of
> > course I see the value: to make existing code work without changes, but I
> > see the following issues.    What do others think?
> > 1. silent activation
> > Apps might explicitly turn on the mapping by doing something like:
> >     dojo.require("dojo.touch");
> > However, it will likely be activated as a side effect, when apps include
> > certain widgets, for example:
> >     dojo.require("dijit.form.HorizontalSlider")
> > That means that the behavior of dojo.connect() will change just by
> loading a
> > certain widget.
>
> I suppose dojo.touch shall be transparent to dijit widgets which means
> dijit like HorizontalSlider won't require dojo.touch.
> If user want to run dijit on mobile, dojo.touch needs be either
> explicitly required in app or in mobile profile, so this issue won't
> occur?
>
> >
> > 2. break in backwards compatibility
> > If there are existing apps that already connect to both onmouse* and
> > ontouch*, they could be broken by this change.    Note that (as explained
> in
> > #1), they don't have to explicitly turn on the mapping feature, they'd
> just
> > need to pull in some widget that uses it.
> >
> > 3. sometimes apps may want to differentiate between touch and mouse
> events
> > Perhaps (for example) an app would want touch to scroll the screen, but
> > mouse movement to do nothing besides moving the mouse.   That's of course
> > for machines that have both a mouse and touch ability.
>
> Auto mapping needs to be turned off for #2 and #3 no matter the
> (existing) handler logic for onmouse* and ontouch* is same or
> different.
>
>
> > In previous mails some have talked about having a flag to dojo.connect()
> to
> > disable the mapping for a particular connection:
> >     dojo.connect(obj, "ontouchstart", ..., "nomapping")
> > That's quite similar to having the default be nomapping, and  to opt in
> to
> > get the mapping by using a special event name:
> >     dojo.connect(obj, "start", ...)
>
> Yep, nice point, which was initially discussed in the proposal, in
> that way, we only do mapping for "start | move | end", one major
> concern was significantly changes to existing code base(dijit, dnd,
> charting etc.)
>
> >
> >
> >
> >
> > On Fri, Mar 4, 2011 at 10: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!
> >> >>>>
> >> >>>> - 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/20110310/e82518e2/attachment-0001.htm 


More information about the dojo-contributors mailing list