Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Tobias Taschner
2020-07-04 22:08:24 +02:00
committed by GitHub
parent 81e3760e4a
commit 1666f58bc6
80 changed files with 192 additions and 192 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/base/readme.txt
View File

@@ -30,7 +30,7 @@ executing simultaneously (portably!) and so on.
--------------------------------------
wxBase can be compiled and used under Win32, mostly any modern Unix system
(including OS X), VMS and BeOS (this release couldn't be tested under
(including macOS), VMS and BeOS (this release couldn't be tested under
these platforms so you might encounter some problems but they should be easy
to solve -- please contact us in this case!)

2
docs/doxygen/groups/funcmacro_atomic.h
View File

@@ -14,7 +14,7 @@ When using multi-threaded applications, it is often required to access or
modify memory which is shared between threads. Atomic integer and pointer
operations are an efficient way to handle this issue (another, less efficient,
way is to use a wxMutex or wxCriticalSection). A native implementation exists
for Windows, Linux, Solaris and OS X; for others, a wxCriticalSection is
for Windows, Linux, Solaris and macOS; for others, a wxCriticalSection is
used to protect the data.
One particular application is reference counting (used by so-called

8
docs/doxygen/mainpages/const_cpp.h
View File

@@ -39,9 +39,9 @@ Notice that for compatibility reasons, this symbol is defined for console
applications under Windows as well, but it should only be used in the GUI code
while <tt>__WINDOWS__</tt> should be used for the platform tests.}
@itemdef{__WXOSX__, OS X GUI using any Apple widget framework (AppKit or UIKit)}
@itemdef{__WXOSX_IPHONE__, OS X iPhone (UIKit)}
@itemdef{__WXOSX_COCOA__, OS X using Cocoa (AppKit)}
@itemdef{__WXOSX_MAC__, OS X (Cocoa)}
@itemdef{__WXOSX_IPHONE__, iPhone (UIKit)}
@itemdef{__WXOSX_COCOA__, macOS using Cocoa (AppKit)}
@itemdef{__WXOSX_MAC__, macOS (Cocoa)}
@itemdef{__WXPM__, OS/2 native Presentation Manager (not used any longer).}
@itemdef{__WXSTUBS__, Stubbed version ('template' wxWin implementation)}
@itemdef{__WXXT__, Xt; mutually exclusive with WX_MOTIF, not implemented in wxWidgets 2.x}
@@ -59,7 +59,7 @@ versions: Cocoa for the desktop and a very early iPhone port. To summarize:
<tt>__WXOSX_MAC__</tt>.
@li If you want to test for wxOSX on the iPhone, use
<tt>__WXOSX_IPHONE__</tt>.
@li If you want to test for any port under OS X, including, for
@li If you want to test for any port under macOS, including, for
example, wxGTK and also wxBase, use <tt>__DARWIN__</tt> (see below).
The convention is to use the <tt>__WX</tt> prefix for these

4
docs/doxygen/mainpages/devtips.h
View File

@@ -114,7 +114,7 @@ include: Microsoft Visual C++ (.vc), Borland C++ (.bcc) and MinGW/Cygwin
(.gcc). Makefiles are provided for the wxWidgets library itself, samples,
demos, and utilities.
On Linux and OS X, you use the @c 'configure' command to generate the
On Linux and macOS, you use the @c 'configure' command to generate the
necessary makefiles. You should also use this method when building with
MinGW/Cygwin on Windows.
@@ -127,7 +127,7 @@ On Windows using a compiler other than MinGW/Cygwin, you would build the
wxWidgets library from the @c "build/msw" directory which contains the relevant
makefiles.
On Windows using MinGW/Cygwin, and on Unix and OS X, you invoke
On Windows using MinGW/Cygwin, and on Unix and macOS, you invoke
'configure' (found in the top-level of the wxWidgets source hierarchy), from
within a suitable empty directory for containing makefiles, object files and
libraries.

2
docs/doxygen/mainpages/introduction.h
View File

@@ -91,7 +91,7 @@ NetBSD, Solaris, AIX, ...) and require GTK+ 2.6 or later or GTK+ 3.x. The
primary supported compiler is GNU g++.
@li wxOSX/Cocoa: This is the native port for Apple computers. wxOSX/Cocoa
supports 32 or 64 bit Intel Macs running OS X 10.7 or later. The port can be
supports 32 or 64 bit Intel Macs running macOS 10.7 or later. The port can be
built either with g++ or clang.
Other platforms (e.g. iOS - with a minimum requirement of iOS 9), compilers (Borland C++

4
docs/doxygen/mainpages/platdetails.h
View File

@@ -52,8 +52,8 @@ starting with 3.1.4. Use @c configure option @c \--with-gtk=2 to use GTK 2.
@section page_port_wxosx wxOSX/Cocoa
wxOSX/Cocoa is the port of wxWidgets for the OS X platform. It requires
OS X 10.7 or later and fully supports 64 bit builds.
wxOSX/Cocoa is the port of wxWidgets for the macOS platform. It requires
macOS 10.7 or later and fully supports 64 bit builds.
@subpage plat_osx_install "Build and Install Instructions"

2
docs/doxygen/mainpages/samples.h
View File

@@ -652,7 +652,7 @@ first argument of @c save, @c load or @c delete, followed by the "service" and
"user" arguments as used by wxSecretStore methods. After storing some password,
you can check that it can be retrieved later and also that it can be seen in
the OS-provided password manager (e.g. credential manager under MSW or keychain
utility under OS X).
utility under macOS).
@sampledir{secretstore}

2
docs/doxygen/overviews/backwardcompatibility.h
View File

@@ -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

2
docs/doxygen/overviews/bitmap.h
View File

@@ -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

4
docs/doxygen/overviews/cmake.md
View File

@@ -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).

6
docs/doxygen/overviews/internationalization.h
View File

@@ -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

4
docs/doxygen/overviews/richtextctrl.h
View File

@@ -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.

2
docs/doxygen/overviews/string.h
View File

@@ -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

2
docs/doxygen/overviews/unicode.h
View File

@@ -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.

6
docs/doxygen/overviews/xrc_format.h
View File

@@ -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

2
docs/ios/install.md
View File

@@ -5,7 +5,7 @@ wxiOS is far from a full supported port, but can be used
as base for simple applications and future improvements.
It requires Xcode with iOS SDK 9.0 or later. Xcode is available
for free in the OS X app store.
for free in the macOS app store.
To build wxiOS you should use Xcode to open the minimal samples
Xcode project file located at:

4
docs/osx/install.md
View File

@@ -1,4 +1,4 @@
wxWidgets for OS X installation {#plat_osx_install}
wxWidgets for macOS installation {#plat_osx_install}
-----------------------------------
[TOC]
@@ -33,7 +33,7 @@ After the compilation completes, use Finder to run the samples and demos
* The source code for the samples is in wxWidgets/samples
* The source code for the demos is in wxWidgets/demos
More information about building on OS X is available in the wxWiki.
More information about building on macOS is available in the wxWiki.
Here are two useful links
* https://wiki.wxwidgets.org/Guides_%26_Tutorials
* https://wiki.wxwidgets.org/Development:_wxMac

4
docs/readme.txt
View File

@@ -97,7 +97,7 @@ This version of wxWidgets supports the following primary platforms:
* Windows XP, Vista, 7, 8 and 10 (32/64 bits).
* Most Unix variants using the GTK+ toolkit (version 2.6 or newer)
* OS X (10.7 or newer) using Cocoa (32/64 bits)
* macOS (10.7 or newer) using Cocoa (32/64 bits)
There is some support for the following platforms:
@@ -116,7 +116,7 @@ Files
wxWidgets is distributed in source form in several archive formats. ZIP and 7z
archives are for Microsoft Windows users and contain the files with DOS/Windows
line endings while the compressed tar archives are for Unix systems (including
OS X) and contain the files with Unix line endings. Please notice that some
macOS) and contain the files with Unix line endings. Please notice that some
Windows tools still don't accept files with Unix line endings and that compiling
sources with DOS line endings under Unix will fail, so please choose the correct
file for your system.