There is a WWDC video that covers it in detail. There's not a way to get nontransient overlay scrollers.
The thoughtful thing is that the NSScrollView api provides methods that give you the right sizes to work with independent of what the user's preference is. The overlay rationale was one about making user content the visual priority. That said, it's tricky to do right but one can use the overlay scrollers and still implement a visual indicator of relative location within the ScrollView. (Think Photoshop inspector palette with a visible rect over the thumbnail image) It's all about the intersection and union of documentView and clipView (a.k.a. ContentView) Implementing custom scrollers is a lot less palatable though. The rubberbanding effect is the sticky area. If you turn it off your scroll view suddenly really stands out as acting different from most of the OS. If you try to do custom scrollers with it on, well, have fun with that. Add Responsive Scrolling to the mix with tracking the momentum. Sent from my iPhone > On 2015/03/05, at 13:25, Graham Cox <graham....@bigpond.com> wrote: > > >> On 5 Mar 2015, at 2:59 pm, Kyle Sluder <k...@ksluder.com> wrote: >> >> Subclass NSScroller and override +isCompatibleWithOverlayScrollers to >> return NO. Then assign an instance of this subclass via >> -setHorizontalScroller:. > > > OK, somewhat long-winded, but I'll give it a go. > > However, I can see another issue. What if I want the overlay style of > scroller, but always visible? Maybe that isn't even possible? When I use > System Preferences to always show, the scroller has an opaque background and > border. It's not the appearance of the overlay scroller I mind, or am > objecting to, it's its transient behaviour that makes it hard to grab the > thumb. I guess I really want an overlay scroller but that stays put. I'm > presuming that the workaround you mention will always give me an old-school > scrollbar. > > My use-case might be rather specific to a set of particular circumstances. > > First, the view in question is very wide, but not often all that tall, > meaning that horizontal scrolling and skimming with the thumb is often > desirable. > > Second, my mouse isn't an Apple mouse, and it only has a vertical scroll > wheel, not a dual-axis scroller. That means that for this wide scrollview, > the scrollwheel isn't too useful, so I'm falling back to grabbing the thumb. > However, the transient scrollbars make it hard to grab, and the vertical > scrollwheel makes it hard to force the scrollbars to show without resorting > to either shift-scrolling with the scrollwheel, or using the accessory > trackpad with my other hand. > > The usual situation is that I have wide scrollview with no vertical scroll > available. With my particular mouse, there's no way with a single hand on my > mouse to show the thumb and scroll the view horizontally; I have to use my > other hand either to press shift or to hit the trackpad. In other words, > one-handed skimming of my wide view is impossible with this mouse and the > default system settings. Maybe Apple don't care about using 3rd party input > devices? Maybe I shouldn't care, it's unlikely to affect my app's users, but > it sure is affecting me. > > --Graham > > > > _______________________________________________ > > 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/dangerwillrobinsondanger%40gmail.com > > This email sent to dangerwillrobinsondan...@gmail.com _______________________________________________ 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
