[dojo-contributors] Initial shape of dojo.touch + dojo.gesture - changes for next patch

Evan Huang evanhuangwei at gmail.com
Wed Mar 9 19:37:13 EST 2011


So as agreed in today's IRC, we will make a bit changes based on the
0.1 version,
1. Don't do any magic mapping
2. Use below new event names to avoid any conflicts with any existing
native mouse/touch usages
    - 'press, move, release' - these new events will work across devices
    - we'll still have chances to change the naming if come up with better ones
3. If a widget want to support gesture, it simply requires
dojo.gesture(which auto requires dojo.touch), and use the standard new
event name:
    - dojo.connect(n, 'press | move | release', callback)
    - dojo.connect(n, 'tap | swipe | ...', callback)

We will try how it works by experimenting on Slider(dnd) and hopefully
we won't need to struggle with auto mapping anymore

- Evan

On Thu, Mar 10, 2011 at 6:41 AM, Chris Mitchell <ccmitchellusa at gmail.com> wrote:
> 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
>


More information about the dojo-contributors mailing list