> On 11 May 2015, at 18:26, Graham Cox <graham....@bigpond.com> wrote: > > >> On 11 May 2015, at 7:15 pm, dangerwillrobinsondan...@gmail.com wrote: >> >> It still receives the same events that are sent from scrolling. > > > I entirely understand that. > > >> All the same things apply about interpreting the events that pass in to the >> scrollWheel: method. >> It is your gateway to handle scrolling input in a view. > > > If so, how? The changes to NSScrollView for responsive scrolling are all > implemented internal to it and NSClipView, and your app is expected to rely > on various new notifications to get hooks into various phases of the whole > sequence of scrolling a view. There is no support or changes to NSEvent, and > nothing in the -[NSResponder scrollWheel:] handler itself that has changed - > only NSScrollView overrides that method to set up a private concurrent event > queue. Maybe within that queue there is some private stuff that gives it more > information but it hasn’t been exposed to the public. > > —Graham > >
I thought they added phase and momentumPhase to NSEvent, plus hasPreciseScrollingDeltas, scrollingDeltaX and scrollingDeltaY to help disambiguate between clicky scrollwheels and draggy trackpads, give finer results and let you know what constitutes one motion. The phase brackets the actual events with Began, Ended, Changed and a few others and the preciseScrollingDeltas are .. more precise. Then when it’s all done you get a momentumPhase for deceleration. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
