Change documentation references from OS X to macOS (#1927)

Since OS X 10.12 it has been named macOS so it makes sense
to reference it in documentation as such, even when it
sometimes refers to older versions which were called (Mac) OS X.

docs/doxygen/overviews/backwardcompatibility.h

@@ -108,7 +108,7 @@ compatible but can also be binary compatible.
 
 Binary compatibility makes it possible to get the maximum benefit from using
 shared libraries, also known as dynamic link libraries (DLLs) on Windows or
-dynamic shared libraries on OS X.
+dynamic shared libraries on macOS.
 
 For example, suppose several applications are installed on a system requiring
 wxWidgets 2.6.0, 2.6.1 and 2.6.2. Since 2.6.2 is backward compatible with the

docs/doxygen/overviews/bitmap.h

@@ -82,7 +82,7 @@ XPM nor BMP formats are appropriate as they don't have support for alpha and
 another format, typically PNG, should be used. wxWidgets provides a similar
 helper for PNG bitmaps called wxBITMAP_PNG() that can be used to either load
 PNG files embedded in resources (meaning either Windows resource section of the
-executable file or OS X "Resource" subdirectory of the application bundle) or
+executable file or macOS "Resource" subdirectory of the application bundle) or
 arrays containing PNG data included into the program code itself.
 
 @see @ref group_class_gdi

docs/doxygen/overviews/cmake.md

@@ -5,7 +5,7 @@ CMake Overview                         {#overview_cmake}
 CMake allows building wxWidgets on various platforms with your preferred build
 system.
 
-Most linux distributions contain CMake as a package on Windows and OS X you can
+Most linux distributions contain CMake as a package on Windows and macOS you can
 download an installer at the [CMake Page](https://cmake.org).
 
 Using the CMake GUI                    {#cmake_gui}
@@ -30,7 +30,7 @@ Using the CMake Command Line           {#cmake_cli}
 
 Run `cmake --help` to see a list of available generators on your platform.
 These can than be specified using the -G command line option. On Windows it
-is recommended to use Visual Studio and on OS X Xcode is recommended.
+is recommended to use Visual Studio and on macOS Xcode is recommended.
 Various build options can be specified using -D see
 [available options](#cmake_options).
 

docs/doxygen/overviews/internationalization.h

@@ -80,12 +80,12 @@ locations when possible.
 
 Depending on the platform, the default location differs. On Windows, it is
 alongside the executable. On Unix, translations are expected to be in
-"$prefix/share/locale". On OS X, application bundle's @em Resources subdirectory
+"$prefix/share/locale". On macOS, application bundle's @em Resources subdirectory
 is used.
 
 In all cases, translations are searched for in subdirectories named using the
 languages codes from ISO 639. The .mo file(s) should be located either directly
-in that directory or in LC_MESSAGES subdirectory. On OS X, ".lproj" extension
+in that directory or in LC_MESSAGES subdirectory. On macOS, ".lproj" extension
 is used for the per-languages Resources subdirectories.
 
 Here's how an app would typically install the files on Unix:
@@ -94,7 +94,7 @@ Here's how an app would typically install the files on Unix:
 /usr/share/locale/de/LC_MESSAGES/myapp.mo
 /usr/share/locale/fr/LC_MESSAGES/myapp.mo
 @endcode
-And on OS X:
+And on macOS:
 @code
 MyApp.app/Contents/MacOS/MyApp
 MyApp.app/Contents/Resources/de.lproj/myapp.mo

docs/doxygen/overviews/richtextctrl.h

@@ -42,7 +42,7 @@ list styles with a renumber option.
 There are a few disadvantages to using wxRichTextCtrl. It is not native, so
 does not behave exactly as a native wxTextCtrl, although common editing
 conventions are followed. Users may miss the built-in spelling correction on
-OS X, or any special character input that may be provided by the native
+macOS, or any special character input that may be provided by the native
 control. It would also be a poor choice if intended users rely on screen
 readers that would be not work well with non-native text input implementation.
 You might mitigate this by providing the choice between wxTextCtrl and
@@ -495,7 +495,7 @@ tables, text boxes, and floating images, in addition to a simplified-HTML mode f
 
 There are also things that could be done to take advantage of the underlying
 text capabilities of the platform; higher-level text formatting APIs are
-available on some platforms, such as OS X, and some of translation from
+available on some platforms, such as macOS, and some of translation from
 high level to low level wxDC API is unnecessary. However this would require
 additions to the wxWidgets API.
 

docs/doxygen/overviews/string.h

@@ -135,7 +135,7 @@ to buffer overflows. At last, C++ has a standard string class (@c std::string).
 why the need for wxString? There are several advantages:
 
 @li <b>Efficiency:</b> Since wxWidgets 3.0 wxString uses @c std::string (in UTF8
-    mode under Linux, Unix and OS X) or @c std::wstring (in UTF16 mode under Windows)
+    mode under Linux, Unix and macOS) or @c std::wstring (in UTF16 mode under Windows)
     internally by default to store its contents. wxString will therefore inherit the
     performance characteristics from @c std::string.
 @li <b>Compatibility:</b> This class tries to combine almost full compatibility

docs/doxygen/overviews/unicode.h

@@ -182,7 +182,7 @@ aware of the potential problems covered by the following section.
 wxWidgets uses the system @c wchar_t in wxString implementation by default
 under all systems. Thus, under Microsoft Windows, UCS-2 (simplified version of
 UTF-16 without support for surrogate characters) is used as @c wchar_t is 2
-bytes on this platform. Under Unix systems, including OS X, UCS-4 (also
+bytes on this platform. Under Unix systems, including macOS, UCS-4 (also
 known as UTF-32) is used by default, however it is also possible to build
 wxWidgets to use UTF-8 internally by passing @c \--enable-utf8 option to
 configure.

docs/doxygen/overviews/xrc_format.h

@@ -2663,15 +2663,15 @@ should be processed on. It is filtered out and ignored on any other platforms.
 Possible elemental values are:
 @beginDefList
 @itemdef{ @c win, Windows }
-@itemdef{ @c mac, OS X (or Mac Classic in wxWidgets version supporting it) }
-@itemdef{ @c unix, Any Unix platform @em except OS X }
+@itemdef{ @c mac, macOS (or Mac Classic in wxWidgets version supporting it) }
+@itemdef{ @c unix, Any Unix platform @em except macOS }
 @endDefList
 
 Examples:
 @code
 <label platform="win">Windows</label>
 <label platform="unix">Unix</label>
-<label platform="mac">OS X</label>
+<label platform="mac">macOS</label>
 <help platform="mac|unix">Not a Windows machine</help>
 @endcode