UI: Inline macOS 13 check

[gxalpha]

Description

Inlines the macOS 13 check for the default device.

Motivation and Context

When I closed #11127 I noticed that there is potential to clean this up.

How Has This Been Tested?

macOS 15
New OBS Settings folder, new device does not get created.

Types of changes

• Code cleanup (non-breaking change which makes code smaller or more readable)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[jcm93]

Part of my original PR's goal was trying to make the meaning of why we were disabling the source on macOS 13 clear (or at least somewhat clear) just from reading the code, and I think this might lose some of that, but overall it's very minor anyway, so no real complaints.

[gxalpha]

Yeah imo that’s a bit overkill, if anything that should just be a comment imo. I can add that.

[PatTheMav]

Overall I'm fine with the changes themselves, my only gripe would be that the reason this function was put into platform-osx.mm was that it's very much a platform-specific check.

The idea being that shouldCreateDefaultAudioSource being a function part of internal API independent(!) of platform and that it happens to return always false on macOS 13 (and vice versa maybe always return true on Windows or Linux).

The reason we have the platform header (and the platform specific TUs) is to put platform-specific code into that source file and not litter the rest of the code with platform-specific conditionals.

[gxalpha]

The reason we have the platform header (and the platform specific TUs) is to put platform-specific code into that source file and not litter the rest of the code with platform-specific conditionals.

I think platform.hpp in the UI and util/platform.h are used very differently.
While this is true for the libobs functions, functions in the UI's header often only have implementations for the operating system where they are used, and calls to them are generally ifdefd (see functions like EnableOSXVSync or EnableOSXDockIcon, but also SetWin32DropStyle,SetProcessPriority for Windows, etc.).

[PatTheMav]

The reason we have the platform header (and the platform specific TUs) is to put platform-specific code into that source file and not litter the rest of the code with platform-specific conditionals.

I think platform.hpp in the UI and util/platform.h are used very differently. While this is true for the libobs functions, functions in the UI's header often only have implementations for the operating system where they are used, and calls to them are generally ifdefd (see functions like EnableOSXVSync or EnableOSXDockIcon, but also SetWin32DropStyle,SetProcessPriority for Windows, etc.).

Yeah as I said, I'm fine with the change but wanted to point out that the whole reason to have platform-specific implementations under a unified header is to avoid using preprocessor conditionals in source code, but we ended up doing both.

[RytoEX]

LGTM