Important notes
Notes relating to the gesture and inking functions.
1. Really important point: When using gestures in Mac OS X the gestures are processed by the application window under the mouse cursor. Dual and multi-touch gestures can be performed on any part of the touch screen but will be processed by the target area. So, for example, if you have a Preview window open and the cursor is in the viewing area then the area will respond to gestures. If the cursor is on the Preview dialog but not in the view area then gestures will be ignored. Since gesture version 2.0.47 Zoom, rotate and scroll actions have an option for either performing the gesture on the item under the mouse cursor or under the position where the gesture occurs on the screen (the mouse cursor is automatically repositioned): e.g.
We were asked if this setting could be made available for any gesture. Unfortunately the current design of the settings dialog does not readily cater for this so although the code is in place to facilitate this request the setting has to be set manually in the settings file.
2. Enable Access for Assistive Devices
Several of the actions that can be invoked by a gesture, such as notification center, require that "Enable Access for Assistive Devices" is turned on in the "Universal Access" system preferences as described below.
Access for assistive devices requirements
A number of functions performed by the gesture software require that ‘Access for Assistive Devices’ be enabled in the system. If this is not enabled then the Gesture GUI will carry an Enable Accessibility option as shown below:
Whilst ‘Access for assistive devices’ is disabled the Gesture GUI will disable any functions that require it to be enabled:
3. Touches simulate tablet input
When this setting is enabled:
· Any mouse events created by Gestures through "Click" and "Click and drag" actions are also tablet events. This is because in OS X tablet events are actually special mouse events with extra tablet data included.
· The "Ink" preference pane will be visible in System Preferences, if it was not already, allowing Inking to be configured. If Inking is enabled, it can be used with Gestures through the "Click" and "Click and drag" actions.
4. Returning from Sleep considerations
At some point during past development we introduced a delay after sleep before the gesture software disabled the driver’s mouse port interface to overcome some strange issues that occurred after returning from sleep that we did not fully understand but the delay overcame. The delay is 10 seconds. During this time the driver and gestures will both post touch data to the OS, resulting in double clicks etc.
Since this delay was added the software has undergone a great deal of development. In our recent tests we found that removing the delay did not cause any issues but we think these were only ever experience by end users and not reproducible in our lab. Because of this we are reluctant to remove this delay altogether but have placed the delay time on a hidden setting for adjustment by end users. This setting can be set using our command line utility with the following command:
upddutils nodevice set "gesture mouse port delay after sleep" N - where N is defined in seconds. 0 = no delay, >10 set to 10.
5. Reset Mouse Cursor
The 'reset mouse cursor' feature has some limitations. It may interfere with normal interaction with menus, since menus respond to the position of the mouse cursor. For example, you could tap a menu, and then the cursor could reset to a position inside the menu but over an item you do not wish to select. It's a minor annoyance and one we could address if it crops up in ‘real world’ usage. Gestures could recognize when a menu is being used and wait to reset the cursor once it closes.
6. Accessibility API issues causing gesture processing delay in 10.11
The appears to be a bug in the Accessibility API whereby querying which UI element is under a point on the screen can take a second or two the first time its done over a particular windows or application. If it is an accessibility bug then there is not much we can do about it and we can just hope it is addressed by Apple in a future update. Gestures uses accessibility in a few specific places: when performing any window-related actions (e.g. close window, minimize window, zoom window), when performing the "Toggle notification center" action, for its "iOS simulator mode" feature, and when scrolling, in order to tell when the element that's being scrolled has reached the top or bottom.
The main concerned is the detrimental effect this could have when scrolling as this is one of the most oft-used actions and the delay could occur anytime scrolling is attempted in an application window that hasn't been scrolled before. All of the rest of the actions are either less critical or the slowdown will only happen once the first time its used.
The biggest culprit is the "iOS Simulator mode" feature, since it uses the accessibility API every single time a new touch begins - this *really* slowed things down in our tests. Given that this is a rarely used feature we've changed it to default to off.
At this point we don't know how widespread this issue is in OS X 10.11 or whether it's likely to affect any systems other than our own test systems. Please advise if you experience this issue.