…pting an ATTACHED_BUILDING_OUT view failed to work and no longer attempting to reverse transitions.
…sues with the built-in gesture support. For example, two touch taps would throw an exception, pinches would fail to register and in particular, supporting multiple gestures failed in a number of scenarios. In order to fix these problems, the gesture code has been rewritten from the top-down. It is now possible to mixin SC.Gesturable to a view and use events to react to multiple gestures concurrently. Examples of the advanced type of behavior that the gesture code allows include: * Responding to single finger, two finger or any other number of touch taps, pinches (2+ touches) or swipes individually or as a group. For example, your code may want to perform different actions when a single finger taps vs. when there is a two finger tap. * A touch session, the time between when the first touch begins and the last touch ends, may contain more than one gesture. For example, it's possible for the user to perform a pinch, then use a third finger to tap, then swipe the remaining fingers. For example, imagine using pinch to scale an image, tap to save the change and then swipe to move it aside all without lifting the fingers. At the least, the ability to perform gestures in a single touch session multiple times, makes the gesture recognition more robust against stray accidental touches. * Swipe gestures can now be configured to match against any arbitrary angles, not just left, right, up & down. * Swipe gestures no longer trigger by simply moving far enough in one direction. They must also move quickly (configurable) and end immediately.
…er when not yet rendered.
…ass method of SC.Touch (SC.Touch.averagedTouch()). This makes it possible to use the functionality to average touches without needing to run through the root responder code.
…it position property which wasn't useful and added to the computation time.
…the overridden value using explicit layouts. This avoids overwriting the entire layout when the design mode changes.
…`, which is meant to contain all code providing support for older browsers. This includes the existing polyfill for `window.requestAnimationFrame` and a brand new polyfill for `Object.keys`. The legacy framework is included by default by requiring `:sproutcore` in a project's or an app's Buildfile. The legacy framework itself requires the `:sproutcore/desktop` framework, which allows for any legacy code in the SproutCore controls to be separated out. Therefore, to build an app that will only work with the newest browsers (probably not a great idea —), you may change your Buildfile requirements to include only the specific SproutCore sub-frameworks you need. For example, config :my_app, :required => [:"sproutcore/desktop", :"sproutcore/datastore"]
… (i.e. the protocol that may be implemented by `SC.Responder` subclasses like `SC.View`).