Also fix spelling mistakes in the documentation files

Run the same codespell command on docs directory.

docs/contributing/binary-compatibility.md

@@ -209,7 +209,7 @@ so a line like this could be added to version-script.in:
     \*wxGenericListCtrl*GetItemFont*;
 
 Allow for the fact that the name mangling is going to vary from compiler to
-complier.
+compiler.
 
 When adding a class you can match all the symbols it adds with a single
 pattern, so long as that pattern is not likely to also match other symbols.

docs/contributing/how-to-add-new-wxUSE_XXX.md

@@ -51,7 +51,7 @@ The following files need to be modified when adding a new `wxUSE_FOO`:
    section. Please keep the alphabetic order.
 
    If there are any dependencies, i.e. `wxUSE_FOO` requires `wxUSE_BAR` and
-   `wxUSE_BAZ`, check for thme here too.
+   `wxUSE_BAZ`, check for them here too.
 
 - `include/wx/msw/chkconf.h` for MSW-specific options
 

docs/contributing/how-to-release.md

@@ -177,7 +177,7 @@ E.g. to create documentation for `v3.0.z` release:
 ## Announcement
 
 Update https://www.wxwidgets.org:
-* Update release information (at least `version` and `released`) in `_data/relases.yml`.
+* Update release information (at least `version` and `released`) in `_data/releases.yml`.
 * Update the list of compilers used for making MSW binaries in
   `downloads/index.md` if necessary (note that there is no need to update
   anything else, the page will dynamically show the release files with the

docs/doxygen/Doxyfile

@@ -214,7 +214,7 @@ ALIASES += rightCurly="}"
 # For indicating a sample location
 ALIASES += sampledir{1}="@e Location: @c samples/\1 subdirectory of your wxWidgets installation or https://github.com/wxWidgets/wxWidgets/tree/master/samples/\1"
 
-# For refering to the corresponding sample in a class document or a overview
+# For referring to the corresponding sample in a class document or a overview
 # Usually placed in the queue of @see
 ALIASES += sample{1}="\ref page_samples_\1"
 

docs/doxygen/groups/class_help.h

@@ -10,7 +10,7 @@
 @defgroup group_class_help Help
 @ingroup group_class
 
-Classes for loading and displaying help manuals or help informations in general.
+Classes for loading and displaying help manuals or help information in general.
 
 */
 

docs/doxygen/mainpages/cat_classes.h

@@ -126,7 +126,7 @@ Controls that are not static can have wxValidator associated with them.
     mode
 @li wxNotebook: A notebook class
 @li wxOwnerDrawnComboBox: A combobox with owner-drawn list items
-@li wxPropertyGrid: A complex control to display hierachical, editable information
+@li wxPropertyGrid: A complex control to display hierarchical, editable information
 @li wxRadioBox: A group of radio buttons
 @li wxRadioButton: A round button to be used with others in a mutually
     exclusive way

docs/doxygen/mainpages/utilities.h

@@ -13,7 +13,7 @@
 
 In addition to the wxWidgets libraries (see @ref page_libs), some utilities
 are available to the users in the @c utils hierarchy (even if some of them are
-explicitly conceived for wxWidgets maintainance and will probably be of
+explicitly conceived for wxWidgets maintenance and will probably be of
 little use to others).
 
 Please note that these utilities only represent the utilities developed and

docs/doxygen/overviews/cmake.md

@@ -26,7 +26,7 @@ Using the CMake Command Line           {#cmake_cli}
 2. Change into the created folder
 3. Run `cmake -G "Unix Makefiles" path_to_wxWidgets_root`
 4. After that you can run `cmake --build .` to start the build process or
-   directly use your choosen build system.
+   directly use your chosen build system.
 
 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

docs/doxygen/overviews/customwidgets.h

@@ -12,7 +12,7 @@
 @tableofcontents
 
 Typically combining the existing @ref group_class_ctrl controls in wxDialogs
-and wxFrames is sufficient to fullfill any GUI design. Using the wxWidgets
+and wxFrames is sufficient to fulfill any GUI design. Using the wxWidgets
 standard controls makes your GUI looks native on all ports and is obviously
 easier and faster.
 

docs/doxygen/overviews/datetime.h

@@ -106,7 +106,7 @@ just @c wxDateTime::Now() + wxDateSpan::Month()).
 
 
 
-@section overview_datetime_arithmetics Date Arithmetics
+@section overview_datetime_arithmetics Date Arithmetic
 
 Many different operations may be performed with the dates, however not all of
 them make sense. For example, multiplying a date by a number is an invalid

docs/doxygen/overviews/printing.h

@@ -84,7 +84,7 @@ The scaling of the drawn image typically differs from the screen to the preview
 and printed images. This class provides a set of routines named
 FitThisSizeToXXX(), MapScreenSizeToXXX(), and GetLogicalXXXRect, which can be
 used to set the user scale and origin of the wxPrintout's DC so that your class
-can easily map your image to the printout withough getting into the details of
+can easily map your image to the printout without getting into the details of
 screen and printer PPI and scaling. See the printing sample for examples of how
 these routines are used.
 

docs/doxygen/overviews/richtextctrl.h

@@ -415,7 +415,7 @@ set the focus back to the top-level object.
 An event will be sent to the control when the focus changes.
 
 When the user clicks on the control, wxRichTextCtrl determines which container
-to set as the current object focus by calling the found container's overrided
+to set as the current object focus by calling the found container's overridden
 wxRichTextObject::AcceptsFocus function. For example, although a table is a
 container, it must not itself be the object focus because there is no text
 editing at the table level. Instead, a cell within the table must accept the

docs/doxygen/overviews/xrc_format.h

@@ -115,7 +115,7 @@ These come in two varieties:
     ("\<label\>Cancel\</label\>"), but they may use nested subelements too (e.g.
     @ref overview_xrcformat_type_font "font property"). A property can only be
     listed once in an object's definition.
- -# Child objects. Window childs, sizers, sizer items or notebook pages
+ -# Child objects. Window children, sizers, sizer items or notebook pages
     are all examples of child objects. They are represented using nested
     @c \<object\> elements and are can be repeated more than once. The specifics
     of which object classes are allowed as children are class-specific and
@@ -1819,7 +1819,7 @@ objects have the following properties:
 @endTable
 
 A wxRibbonPage may have children of any type derived from wxRibbonControl.
-Most commontly, wxRibbonPanel is used. As a special case, the @c panel
+Most commonly, wxRibbonPanel is used. As a special case, the @c panel
 pseudo-class may be used instead of @c wxRibbonPanel when used as wxRibbonPage
 children.
 

docs/doxygen/scripts/write_info_tag.py

@@ -14,7 +14,7 @@ fname = sys.argv[1] + ".plist"
 # The second argument is the key to replace
 key = sys.argv[2]
 
-# The thrid argument is the value of the key
+# The third argument is the value of the key
 val = sys.argv[3]
 
 # Handle boolean values

docs/gtk/nonnative.txt

@@ -16,7 +16,7 @@ List of classes which should use their native GTK+ equivalents but don't:
     Not possible because GTK's GtkHPane and GtkVPane
     only support either horizontal or vertical panes
     (therefore their names) whereas wxSplitterWindow
-    supports both and can even change orientiation at
+    supports both and can even change orientation at
     runtime.
 
 - wxDatePickerCtrl

docs/gtk/overview.md

@@ -14,7 +14,7 @@ to write wxWidgets applications for the [GNOME][] desktop, I will focus on the
 GTK+ port, which is generally referred to as wxGTK.
 
 wxGTK still supports the old version GTK+ 1.2, but it now defaults to the
-uptodate version GTK+ 2.X, which is the basis for the current GNOME desktop. By
+up-to-date version GTK+ 2.X, which is the basis for the current GNOME desktop. By
 way of using GTK+ 2.X and its underlying text rendering library [Pango][], wxGTK
 fully supports the Unicode character set and it can render text in any language
 and script, that is supported by Pango.
@@ -111,7 +111,7 @@ single application binary. This was possible since most of the relevant
 functionality was either located in the only required library (GTK+) or was
 implemented within wxWidgets. Recent development outside the actual GTK+ project
 has made it necessary to rethink this design and make use of other projects'
-features in order to stay uptodate with current techological trends. Therefore,
+features in order to stay up-to-date with current techological trends. Therefore,
 a system was implemented within wxWidgets that queries the system at runtime
 about various libraries and makes use of their features whenever possible, but
 falls back to a reasonable solution if not. The result is that you can create

docs/msw/install.md

@@ -603,7 +603,7 @@ application.
 Advanced Library Configurations        {#msw_advanced}
 ===============================
 Build instructions to less common library configurations using different UI
-backends are avaiable here.
+backends are available here.
 
 @subpage plat_msw_msys2 "Building with Win32 MSys2 backend"
 

docs/publicity/WoWoW30.html

@@ -75,7 +75,7 @@ documentation had to be corrected by hand making this effort one of
 the biggest in the development cycle leading up wxWidgets 3.0.
 Additionally, tools were written to automatically compare the
 signature of the many class methods to the documentation. The result
-is more correct documentation with better formating and built-in
+is more correct documentation with better formatting and built-in
 searching and screenshots of many controls. Since Doxygen is a
 wide-spread format and easy to learn, the new documentation is much
 easier to edit, correct and read. See the <A HREF="https://docs.wxwidgets.org/trunk/index.html">wxWidgets
@@ -147,10 +147,10 @@ see <A HREF="https://docs.wxwidgets.org/trunk/classwx_d_c.html">wxDC</A>,
 <A HREF="https://docs.wxwidgets.org/trunk/classwx_brush.html">wxBrush</A>),
 it has not changed much since its initial inception and so the code
 was completely reorganized using a single set of frontend classes and
-different backends which will make maintainance much easier without
+different backends which will make maintenance much easier without
 having to care for binary backwards compatibility and it also helped
 isolate a number of subtle platform differences. The old drawing API
-is good enough for many tasks and reflects the drawing capabilites of
+is good enough for many tasks and reflects the drawing capabilities of
 the 1990's but it didn't make use of advanced features such as
 transparency, anti-aliasing and free matrix transforms of modern 2D
 graphics systems such as GDI+ on Windows, Cairo on Linux (and
@@ -165,12 +165,12 @@ wxBRUSHSTYLE_SOLID etc. and the reference counting system was
 streamlined and made identical on all platforms.</P>
 <H3 CLASS="western">Changes to wxBase</H3>
 <P ALIGN=JUSTIFY>wxBase is the name of the non-GUI part of wxWidgets
-libary which provides basic class such as the aforementioned wxString
+library which provides basic class such as the aforementioned wxString
 class, container classes, as well as classes for threading,
 networking, XML parsing, path and configuration management, logging,
 debugging etc. These functions and classes have been separated into
 their own library both for being able to write non-GUI apps as well
-as to make maintainance easier through reduced interdependence.
+as to make maintenance easier through reduced interdependence.
 </P>
 <P ALIGN=JUSTIFY>Many of the changes to wxString and the container
 classes are located in wxBase, but on top of that support to wxBase

docs/publicity/slogans.txt

@@ -85,7 +85,7 @@ Hmm. I might buy a mug that had, say, a wxLogo and "wxWidgets" (and
 maybe the website URL underneath in smaller type) on one side and
 "Specialization is for insects ... and templates" on the other.
 
-.. only if it held at leat a full half (imperial) pint, mind. Not
+.. only if it held at least a full half (imperial) pint, mind. Not
 one of those wussy 8.5 fl.oz. jobbies.
 
 That'd be a nice ice-breaker when working at a new client's site -

docs/qt/architecture.md

@@ -2,11 +2,11 @@
 
 ## Internals
 
-wxQT uses the same techniques like other ports to wrap the Qt toolkit classes inside the wxWidget hierachy (especially similar to wxGTK).
+wxQT uses the same techniques like other ports to wrap the Qt toolkit classes inside the wxWidget hierarchy (especially similar to wxGTK).
 
 ### Current (original) Approach
 
-An '''internal pointer m_qtWindow''' in wxWindow holds the reference to the QWidget (or derived) counterpart, and is accesible through the virtual method '''GetHandle'''.
+An '''internal pointer m_qtWindow''' in wxWindow holds the reference to the QWidget (or derived) counterpart, and is accessible through the virtual method '''GetHandle'''.
 This pointer and other window styles are set up in the '''PostCreation''' method that must be called by the derived classes (mostly controls) to initialize the widget correctly.
 Not doing so will cause painting and deletion issues, as the base class  will not know how to handle the Qt widget.
 wxControl even provides a protected method '''QtCreateControl''' that will do the common initialization (including post creation step, moving, sizing, etc., and calling the base to add the child to the parent).
@@ -19,7 +19,7 @@ Many controls have also other pointers to allow to map different sub-widgets and
 ### New (tentative) Approach
 
 In the other end, Top Level Windows (frames and dialogs) '''uses directly the internal window pointer''', doing a static cast to return the correct type for GetHandle, avoiding multilevel pointer hierarchies.
-This would be the ideal solution, but not all classes could be mapped 1:1 and that could introduce potential issues (i.e. invalid static casts) and more boilerplate due to additional specific accesor methods.
+This would be the ideal solution, but not all classes could be mapped 1:1 and that could introduce potential issues (i.e. invalid static casts) and more boilerplate due to additional specific accessor methods.
 
 For a longer discussion of pro and cons, see [PR#43 comments](https://github.com/reingart/wxWidgets/pull/43)
 
@@ -59,7 +59,7 @@ The approach chosen was to use templates to help inherit QObject's (QWidget), pr
 
 ### Delete later
 
-Both templates also have some safety checks to avoid invalid spurious access to deleted wx objects (using a special pointer to the wx instance stored in the Qt object, that is reseted to NULL when the wx counterpart is marked to deletion).
+Both templates also have some safety checks to avoid invalid spurious access to deleted wx objects (using a special pointer to the wx instance stored in the Qt object, that is reset to NULL when the wx counterpart is marked to deletion).
 
 This is due that in some situations, Qt object could still be referenced in the Qt event queue, so it cannot be removed immediately.
 

docs/qt/install.md

@@ -140,7 +140,7 @@ the android_armv5/ android_armv7/ android_x86/ pre-compiled folders to
 cross-compile for that architectures)
 
 Then, create a build directory (under the wxWidgets folder), configure for
-Andrid (disable currently unsupported/uneeded features) and run make:
+Android (disable currently unsupported/unneeded features) and run make:
 
     cd ~/src/wxWidgets
     mkdir bldqt5droid