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

Evan Huang evanhuangwei at gmail.com
Fri Mar 11 11:30:20 EST 2011


On Fri, Mar 11, 2011 at 9:47 PM, Kris Zyp <kzyp at dojotoolkit.org> wrote:
> Thinking more about this... the side-effect based approach of adding new
> events to dojo.connect, and effectively modifying it's behavior feels
> less than ideal to me. Modules should avoid modifying other modules if
> possible. As Bill mentioned, the behavior of dojo.connect shouldn't
> depend on which modules have been loaded (which may not be visible at

How about thinking in this way - we make the base of touch & gesture
oob available and loaded by default - either through the
dojo/_base/event.js or other ways, making sure the extra code size
ideally small. The only thing done across widgets would be requiring
various gesture impl(singleton). e.g. dojo.gestures.Tap/Swipe -
requiring gesture impl doesn't change the behavior of dojo.connect(),
but only registering new gesture events that's actually similar as
loading plugins on demand.

> all within a module's context). What if someone else creates a "tap"
> event and it collides with dojo.gesture's? Maybe there is a better way
> of extending dojo.connect.

Agree,  need some more thoughts on this. BTW, they can still customize
the "tap" gesture behavior by overriding the default
dojo.gestures.Tap?

>
> How about we add support to dojo.connect to take a function as the
> "event" argument (the second parameter in dojo.connect, first in
> Nodelist.connect, etc.)? When dojo.connect is called with the "event"
> argument as a function, it will simply delegate to that function,
> calling it with the target/obj and callback function as arguments. Then
> one can use dojo.touch like:
> dojo.connect(n, dojo.touch.start, callback);
> or
> dojo.connect(n, dojo.touch.press, callback);
> and
> dojo.connect(n, dojo.gesture.swipe, callback);
>
> This produces no unexpected side effects, and is a system that is highly
> extensible for any third-party/end-user to create new events without
> conflict.

Interesting idea :-)  I suppose within dojo.touch.press we still do
the routine dojo.connect()?

> Kris
>
> On 3/9/2011 5:37 PM, Evan Huang wrote:
>> 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
>>>
>> _______________________________________________
>> 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