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

Chris Mitchell ccmitchellusa at gmail.com
Wed Mar 9 17:41:22 EST 2011


agree, i'd rather wigets be touch enabled oob. and not have magic mapping.  magic mapping could be a quick and dirty way to get a dijit touch enabled (mixin?), but dont think its very safe to default the magic globally.

-chris

On Mar 9, 2011, at 4:37 PM, Bill Keese <bill at dojotoolkit.org> wrote:

> 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
> >
> >
> 
> _______________________________________________
> 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/20110309/59819925/attachment-0001.htm 


More information about the dojo-contributors mailing list