Fix playback history window doesn't respect reduce motion, #4870

[low-batt]

This commit will change IINA to adhere to the Apple Human Interface Guidelines with respects to the macOS Reduced motion setting. With these changes IINA will reduce, not eliminate, animations when the macOS Reduced motion setting is enabled. When this setting is enabled IINA will fade in the sidebar instead of sliding it into view. All other changes to animation behavior, such as how IINA transitions in and out of full screen mode, are provide by AppKit.

For users who are hyper sensitive to motion this commit adds an Enable animations setting to the UI settings tab in a new Animations section at the bottom of the panel. Disabling this setting will eliminate many, but not all, animated transition effects.

• I have read CONTRIBUTING.md
• This implements/fixes issue Playback history window doesn't respect reduce motion #4870.

---

Description:

[saagarjha]

Reduce motion doesn't mean "turn off all animations", it means "avoid problematic transitions that are likely to cause people to feel disoriented". This animation provides important context to a user interaction and seems like a poor choice to disable unless it is causing issues for people.

[low-batt]

Apple has recognized that sliding is causing issues for such people. The Human Interface Guidelines in the Motion section provides this guidance:

• Replace a slide with a fade to avoid motion

I couldn't find an easy way to make NSOutlineView first fade the item before making it just disappear. Is there a way to do that?

I could break the connection with the macOS reduce motion setting and create a Use animations checkbox in IINA's general settings in the behavior section. Should I implement that?

[saagarjha]

IMO if you think this would be a problem, we should file a feedback and get Apple to implement it in NSOutlineView rather than trying to roll it ourselves.

[low-batt]

I am going to move this to a draft until I have time to add an IINA setting for controlling animations.

It used to be that people sensitive to motion were using the defaults command to set macOS properties that controlled AppKit animations. I think it was starting with OS X Mountain Lion that some of these properties stopped working. More properties stopped working with the releases that followed. Since that time people have been giving Apple feedback on this. I'm expecting the feedback goes to the group that handles accessibility. Relative to the other kinds of impairments this group must address I would expect reducing motion sickness to be a low priority.

But recently I have noticed changes. My guess is that two things have brought some attention to this problem. The first was the need to support the CSS prefers-reduced-motion feature in Safari and Apple's web pages. The second is that with visionOS Apple has to worry about animations contributing to virtual reality sickness. Possibility this is why the accessibility portion of the HIG that covers motion was updated and enlarged. There is also now a separate motion section. In that section under Best Practices it says:

Make motion optional. There are several reasons why people might not experience movement in your app, so it’s essential to avoid using it as the only way to communicate important information. For example, people can turn on the Reduce Motion accessibility setting to minimize or eliminate animations. For guidance, see Motion.

I don't remember Apple ever mentioning eliminate animations in the HIG before. I'm hoping Apple is starting to recognize the problems sliding and zooming trigger in some people.

It definitely would be good to get Apple to enhance NSOutlineView, but that won't provide a solution for older versions of macOS.

[low-batt]

With Reduced motion now only causing IINA to replace the slide animation with a fade when showing/hiding the sidebar, I'm sure Apple would approve of IINA's behavior when this setting is enabled.

Reviewers should take a close look at the showSideBar and hideSideBar methods in MainWindowController. I had a hard time getting the animations to switch between sliding and fading. Is there a cleaner way to code this?

[low-batt]

This is what the new setting looks like:

[low-batt]

After thinking about the code some more I made one more fix.

[svobs]

Reviewers should take a close look at the showSideBar and hideSideBar methods in MainWindowController. I had a hard time getting the animations to switch between sliding and fading. Is there a cleaner way to code this?

Trying out the built product, the fade effect seems to be working as desired... But I see you're only manipulating sideBarView.alphaValue to do an explicit fade in hideSideBar and not showSideBar. Is there a reason you didn't use alphaValue for both? Looks like the fade is still happening for the latter case via an implicit animation which results from sideBarView.isHidden being toggled inside an animation group. I've found this mechanism to be less robust in general than when using alphaValue, though in this case it's probably safe enough because the layout changes being made are relatively simple.

[low-batt]

I originally attempted to just use alphaValue. I had showSideBar set alphaValue to zero and then animate it to 1 to fade-in the sidebar. That did not work. The sidebar was fully opaque from the start. To get that to work I had to set alphaValue to zero outside of showSideBar. That complicated the code a lot. So I switched to animating isHidden to false to fade-in the sidebar. That worked. But animating isHidden to true did not fade-out the sidebar. It just immediately disappeared. I found others discussing this. They had to use alphaValue to get the fade-out to work. I tried that and it worked. It makes no sense to me why isHidden works for fade-in but not for fade-out. I was hoping somebody would know a trick to get this to work in a cleaner way.

[uiryuu]

I really don't think this is necessary. For one, I support @saagarjha's opinion. We really shouldn't mess NSOutlineView up by ourselves. With reduce motion enabled in the system settings, I don't observe one app (including Apple's apps, like Music, Xcode) removes the motion in the NSOutlineView. Besides, introducing another "enable animations" in the IINA settings, which only a very small number of users will use, along side the "reduce motion" already exists in the system accessibility setting, will cause further confusion to users.