Also, switch to use the new divider styles in most places. The remaining usage of the old "OakCreateLine" functions are in the OakChooser windows. These will be refactor for better dark mode support next.
Newer versions of clang now warn when using API's that are only available on OS version newer than the target OS unless they are guarded using `@available`.
This is temporary and should be remove when we move away from older versions of Xcode.
This introduces the `OakBackgroundFillViewStyle` enum with styles that are dark mode aware and should lead to more consistent use between UI elements in the future. Also, convert OTVStatusBar and OFBHeaderView to use the new style enum.
Apple's clang (Apple LLVM version 8.0.0 (clang-800.0.24.1)) as shipped with Xcode 8 now supports `thread_local`. This effectively reverts commits: 14c6a70f3d1aba9d1d1a1a and 172ce9d.
The replacement API¹ did not appear until the 10.10 SDK, although it might be usable from 10.9.2, but as we currently support 10.8, we cannot use it.
¹ [[NSProcessInfo processInfo] operatingSystemVersion]
This can be used when the key is name spaced, e.g. `/foo/bar` or `foo.bar`. Here we can erase everything under foo by using `/foo/` or `foo.` respectively.
This was previously done because the function wasn’t available until 10.7, but since that is (now) our deployment target, there is no need to wrap the call.
This makes the abstraction redundant and it should be removed. I am doing that as a multi-step process, since the previous implementation was blocking tests from being updated to the new (dispatch queue based) test system.
The standard doesn’t care which side the keyword is placed on, but placing it on the right makes it easier to read types.
E.g. reading “int const* const” from right to left we get “const pointer to const integer”.
This is mainly because the SOMAXCONN constant looks better (in the source) than some arbitrarily chosen number. The constant is presently defined as 128 so it doesn’t seem wasteful, and presumably the queue will only take up space if we are not actually responding to socket connections.
The mutex was locked to ensure that the client object did not go away, but the client’s code may terminate the program which destroys the server_t instance and thereby the mutex itself, which would previously cause an assertion to trigger, since the mutex was locked during destruction.
In practice there is no issue with the mutex not being locked while accessing the client object, as “unregister_client” and “master_run” are both called from the main thread, except for tests, but here we do not unregister client objects before their requests have been handled.
