Oh yeah, this also means that users don't have to set self.preferredContentSize themselves. I previously suggested this as a band-aid in #9 (comment).

Merging this PR should probably have to wait until #26 has been merged. This PR still has some issues that could be fixed more easily then.

Looking forward to testing this when the others are merged :)

Merging this PR should probably have to wait until #26 has been merged.

#26 is merged.

Phew, this took way too long.
I think I fixed all the remaining issues.
In my local testing, everything works with the exception of a small animation glitch:

That might just be my weird Auto Layout setup though, so YMMV.

I would have squashed the commits on my end, but I accidentally nuked my repository once before. I hope GitHub gives you the option of squashing this PR on merge.

Another thing I noticed is that the "Switch preference style" button will cause the example app to crash without writing anything to the error log. Any idea why that could happen?

Here's the crash reason. I don't think I'm up to the task of fixing this.

Termination Reason:    DYLD, [0x4] Symbol missing

Dyld Error Message:
  Symbol not found: _$s11Preferences0A16WindowControllerC15preferencePanes5style8animatedACSayAA14PreferencePane_pG_AA0A5StyleOSbtcfC
  Referenced from: /Users/USER/Library/Developer/Xcode/DerivedData/Preferences-chbqhxqmtqgxidbbpgpukucdvrqm/Build/Products/Debug/PreferencesExample.app/Contents/MacOS/PreferencesExample
  Expected in: /Users/USER/Library/Developer/Xcode/DerivedData/Preferences-gwqlpraenvjtwsgxahxalmfcujxq/Build/Products/Debug/Preferences.framework/Versions/A/Preferences

Like with most other things in Xcode, deleting the DerivedData directory got rid of that error. welp 🤷‍♂

On my end, the animations are missing as well, regardless of whether Auto Layout is disabled or not. Additionally, when changing tabs for the first time after opening the window, the disappearing view controller slides out of the window:

I'm not sure what happens here.

Might I suggest removing animations altogether? While they look and feel nice when they work, they also seem to break in interesting ways in situations where the layout of views and view controllers is modified directly. And while you're right that there's no unified standard for preference windows, the behavior of the animation-less example window matches that of Finder and Safari's preference windows.

That's an interesting crash, and weird app behavior. Which macOS version are you on? I remember that I disabled the animated flag for non-Mojave build because the calculations were off even worse.

I'm on 10.14.5. I don't think the app crash was actually related to any code in this repository, my Xcode project just somehow got mangled. Deleting and re-cloning it fixed it.

Ok. So the latest GIF you posted is how things look consistently on your machine now?

Might I suggest removing animations altogether? While they look and feel nice when they work, they also seem to break in interesting ways in situations where the layout of views and view controllers is modified directly. And while you're right that there's no unified standard for preference windows, the behavior of the animation-less example window matches that of Finder and Safari's preference windows.

Your GIF's look matches what I see in e.g. Finder preferences: the window frame animates, the contents just appear suddenly. Do you want to suggest a change to this, or is this already the desired behavior and you suggest getting rid of the setting?

Yeah, it's how things look on my machine now. That's with the changes I made though, the version currently available in this repository will probably look different.

I haven't removed animations in my version yet. The animations breaking are just a side effect of my code changes, hence why I suggested removing them. Attempting to fight Auto Layout to get animations will only lead to pain.

Another thing that's probably hard to spot: When the GIF's animation restarts and I switch away from the Advanced tab, you can see the "Advanced" label animate downwards out of the window frame for a split second. That's another animation bug.

Your GIF's look matches what I see in e.g. Finder preferences: the window frame animates, the contents just appear suddenly.

I agree. That's how it should work.

In master:

• animate: true - the window animates the resize and the content also fade-slides in from the bottom.

What we should change it to:

• animate: true - the window animates the resize and the content just appears after the window resize animation is done.

@SamusAranX Can you remove the content fade-slide animation? That should fix all the current issues, right?

It should fix the issues, but I don't even know how I managed to make the example project behave like it did in the GIF in the first place 😅
When I opened and ran the example project just now, I couldn't reproduce the behavior.

Also, I can't get the two view controllers to hide themselves during the resizing animation. I'm not that familiar with the animation system on macOS.

Just an idea to toy with: maybe it helps to resize the window and in the completion handler of the window resize animation replace the view controllers, but not earlier.

Just an idea to toy with: maybe it helps to resize the window and in the completion handler of the window resize animation replace the view controllers, but not earlier.

@SamusAranX Could you try that?

It's the final few exam weeks where I am, so I'm kind of out of time 😅
I'll get to it as soon as I can though!

I finally found the time to mess around some more. Now (as of commit 90e400f in my fork), the preferences window works as I expect it to:

The latest merge of master into my branch breaks it though, because PreferencePane's viewController property was removed. I was relying on that to cache window measurements.

because PreferencePane's viewController property was removed

It was removed as it's moot. The PreferencePane protocol is now guaranteed to be a NSViewController. So instead of using .viewController, you can just use self.

Sorry for the force push, I messed up my commits halfway through and had to get rid of them.

Commit da9ebc1 attempts to fix view controller opacity animations by explicitly setting .wantsLayer = true on their views so the optional chain right afterwards always has a layer to work with. Instead of trying to find a completion handler that runs after the window frame animation ends, I just used DispatchQueue.main.asyncAfter with a delay of 250ms, since the animation takes roughly that long. In practice, there's no visible difference.

I also tried making it so that enabling Reduce Motion in the Accessibility panel disables the animation altogether, but I couldn't find a way to query the state of that setting programmatically.
A project for another day, perhaps.

In the example app, I think the content animation makes sense the way it looks with your changes. Can you check on the segmented control implementation, though? Its position animates in a very jumpy way now.

Screen captures here: https://imgur.com/a/LP34fv1

I've noticed that even with the regular toolbar style. It seems the toolbar's width isn't updated continuously while animating. Honestly, I'm not sure how much of this is in the code and how much of it is the OS's doing. I'm also not sure if this is something I can fix. The segmented control implementation already went way over my head.

Hi everyone! It seems this PR was going well but then activity stopped. Is this work abandoned? Cheers!

Closing as this is not moving forward and the PR fork has been deleted.