I’ve been implementing a scrolling canvas but there’s a way to scroll I haven’t been able to crack. The way OS X scroll works when a magic mouse and magic trackpad (and some hardware mouse wheels) are used. This scrolling is more “natural” and feels sort of “elastic”. It usually goes on with some inertia after being released (and even usually includes a “bounce” at the end, although this is not hard to code).
I have tried mimicking it but it obviously doesn’t feel “native” because it isn’t. Some custom controls (like Einhugur’s Stylegrid) implement it in a really weird way, where the scroll is translated into pagedows, which makes it work even further from native (in a long list I can do a quick flick and Einhugur’s Stylegrid will scroll by itself for ten seconds, if the list is long enough).
Is there a way to bring the native scrolling functionality to a custom or built-in control?
The listbox doesn’t feel native either but this is in a big way a result of it not scrolling at pixel-level, so it can’t ever feel smooth, but I assume it should be possible to implement this scroll behaviour in scrollable canvases, at least.
Although not in version 1, I am going to tackle this in SSG_ListBox. Basically, what you need to do is have a scroll bar with values e.g. 0 to 100. You need some kind of a “snap back” integer property that basically follows the scroll bar except when scroll bar value is 0 or 100 and you get a MouseWheel in opposite direction. That MouseWheel should bump the snap lock value outside the scroll bar bounds, and a Timer could pull it back into bounds. The magic would be in how the timer pulls it back, maybe not quite linearly.
[quote=26308:@Brad Hutchings]Although not in version 1, I am going to tackle this in SSG_ListBox. Basically, what you need to do is have a scroll bar with values e.g. 0 to 100. You need some kind of a “snap back” integer property that basically follows the scroll bar except when scroll bar value is 0 or 100 and you get a MouseWheel in opposite direction. That MouseWheel should bump the snap lock value outside the scroll bar bounds, and a Timer could pull it back into bounds. The magic would be in how the timer pulls it back, maybe not quite linearly.
Make any sense?
[/quote]
I believe that type of scroll is supposed to model the physics of the real world which is what makes it “intuitive”.
The amount of momentum imparted depends the speed and length of the initial scroll. (easy to see using a magic mouse) How it slows (decelerates) should act as friction would act on a moving object.
I’m not sure what platform you’re looking for, but if it’s for a Mac, I have a demo project of a NSScrollView that works simply, but nicely on a large image. Email me at maui tom at maui dot net if you’re interested.
Presumably, internally, the Apple class applies physics parameters to the scrolling, mass, velocity, acceleration, deceleration, etc. to the animation of this feel and behavior. Looking at the delta’s in the MouseWheel event in Xojo, I don’t think it’s granularity will give you enough information to do it as well. Apple has Protocols associated with its’ NSView that aren’t exposed in Xojo.
I’d be more inclined to guess that they use models which feel about right but are a lot simpler under the hood than even Newtonian physics. At any rate, it’s not rocket science to get the bounce-back mechanism right. You can do it with a ScrollBar subclass and a Timer. Parameter tuning is a little more interesting, depending on your model.
Agreed it can be done like that, maybe nicely, maybe crudely or maybe somewhere in between. I see getting the numbers quickly enough and accurately enough in native Xojo would be tricky and maybe not doable to “feel” good. And even if you could get them, applying the numbers in a smooth, concise, repeatable animatable manner is the real obstacle on all platforms. I could be wrong of course.
But I’m quite confident to say that Apple and their legion of brilliant engineers doesn’t hack things together like that in any shape or manner. They skillfully look at the big picture of reusing these types of behaviors in every aspect of their total UI designs with reusable classes, categories, protocols, etc. and MVC designs that use a state-of-the-art graphics pipeline.
I don’t know what your implementation looks like, but please don’t change the superview of an existing Xojo control in order to host it in the NSScrollView. This is absolutely unsupported and I can imagine quite a few things breaking.
[quote=26286:@Eduardo Gutierrez de Oliveira]Hello,
I’ve been implementing a scrolling canvas but there’s a way to scroll I haven’t been able to crack. The way OS X scroll works when a magic mouse and magic trackpad (and some hardware mouse wheels) are used. This scrolling is more “natural” and feels sort of “elastic”. It usually goes on with some inertia after being released (and even usually includes a “bounce” at the end, although this is not hard to code).
I have tried mimicking it but it obviously doesn’t feel “native” because it isn’t. Some custom controls (like Einhugur’s Stylegrid) implement it in a really weird way, where the scroll is translated into pagedows, which makes it work even further from native (in a long list I can do a quick flick and Einhugur’s Stylegrid will scroll by itself for ten seconds, if the list is long enough).
Is there a way to bring the native scrolling functionality to a custom or built-in control?
The listbox doesn’t feel native either but this is in a big way a result of it not scrolling at pixel-level, so it can’t ever feel smooth, but I assume it should be possible to implement this scroll behaviour in scrollable canvases, at least.[/quote]
Eduardo did you find code that accomplishes the “elastic snapback” feature? I also have been looking for something like this on listboxes and scrolling in general.
The inertial “energy” is based on the start point and release point… If you only scroll say 5 “clicks”, the value could be “10 more”…10 “clicks”…20 more… so on and so forth…then a timer is used in the background to continue sliding the listbox to reach the additional “clicks”… decreasing in speed (steps) in an exponential fashion. There are a number of Javascript implementations which can easily be transposed to desktop controls using the the same technique… or I can create a demo
No, the trackpad generates scroll events beyond the physical scroll like a mousewheel would have. It’s part of a gesture. You can subclass your control to handle it, or use an NSScrollview to contain your content.
I simulate the scrolling and snapback in piDogScrollingCanvas, but it’s not perfect.
[quote=89046:@jim mckay]No, the trackpad generates scroll events beyond the physical scroll like a mousewheel would have. It’s part of a gesture. You can subclass your control to handle it, or use an NSScrollview to contain your content.
I simulate the scrolling and snapback in piDogScrollingCanvas, but it’s not perfect.[/quote]
Windows and Linux don’t have gestures…or an NSScrollView api I’ll make a cross-platform listbox demo.
Right, that’s why piDogScrollingCanvas simulates the inertia and snapback.
I believe the OP was asking in regards to native OSX controls. ie NSScrollView
A Xojo listbox would never work properly as it can only scroll in full-rows. For the “proper” effect it’s necessary to have pixel-level scrolling.
In the sample inertial scrolling you posted this is so jarringly obvious it makes the listbox appear broken (also, on trackpads, it gets all inputs wrong and jumps to the end or scrolls back seemingly randomly).
The ideal would be to have access to the native animations (which means having them on OS X but not on Windows)
