Various minor text tweaks here and there

docs/MigrationGuide.rst

@@ -106,12 +106,12 @@ versions of wxPython, in order to help you prepare for the transition.
 Unicode and Auto-Converting Strings
 -----------------------------------
 
-Starting with the wxPython 2.9 release series, there are no longer
-separate ansi/Unicode builds of wxPython.  All wxPython builds are now
-essentially the same as the old Unicode builds. This means that all
-string objects passed to wx API functions or methods are converted to
-Unicode before calling the C++ function or method.  By default Classic
-wxPython would use the encoding specified by the locale that was
+Starting with the wxPython 2.9 release series, there are no longer separate
+ansi/Unicode builds of wxPython.  All wxPython builds are now essentially the
+same as the old Unicode builds. This means that all string objects (in Python
+2.7) or bytes objects (Python 3+) passed to wx API functions or methods are
+converted to Unicode before calling the C++ function or method.  By default
+Classic wxPython would use the encoding specified by the locale that was
 current at the time of the import of the wx module.
 
 However using the default locale could sometimes cause issues because
@@ -122,7 +122,7 @@ their code with.
 
 Project Phoenix takes this Unicode simplification one step further by
 stipulating that only the utf-8 encoding will be used for
-auto-converting string objects to the Unicode objects that will be
+auto-converting string/bytes objects to the Unicode objects that will be
 passed on to the wx APIs.  If you need to deal with text using a
 different encoding then you will need to convert it to Unicode
 yourself before passing the text to the wx API.  For the most part this
@@ -428,7 +428,7 @@ Frame for the content.
 wx.PyEvent and wx.PyCommandEvent
 --------------------------------
 
-Unlike most other ``wx.Py`` classes these two still exist in Phoenix, and are
+Unlike most other ``wx.Py*`` classes these two still exist in Phoenix, and are
 still the base classes that you should use when creating your own custom
 event classes. For the most part they work just like they did in Classic, and
 they take care of ensuring that any Python attributes that you assign to

docs/sphinx/_templates/main.html

@@ -8,6 +8,12 @@
     last updated |TODAY| from git revision |VCSREV|.
   </p>
 
+    <p>
+        If you are porting your code from Classic wxPython, be sure to read the
+        <a href="MigrationGuide.html">Migration Guide</a> to get a better feel for
+        how some things have changed.
+    </p>
+
 <div class="admonition note">
  <p class="first admonition-title">Note</p>
 

packaging/README-sdist_demo.txt

@@ -12,5 +12,5 @@ from a command line like this::
 
 Each of the folders in the samples folder contains one or more standalone
 applications demonstrating how to use certain features of wxPython.  Examine
-the source code in each sample to see how to run them.
+the source code in each sample folder to see how to run them and what they do.
 

setup.py

@@ -42,19 +42,28 @@ PLATFORMS        = "WIN32,WIN64,OSX,POSIX"
 KEYWORDS         = "GUI,wx,wxWindows,wxWidgets,cross-platform,awesome"
 
 LONG_DESCRIPTION = """\
-wxPython_Phoenix is a new implementation of wxPython focused on
-improving speed, maintainability and extensibility. Just like "Classic"
-wxPython it wraps the wxWidgets C++ toolkit and provides access to the user
-interface portions of the wx API, enabling Python applications to have a GUI
-on Windows, Macs or Unix systems with a native look and feel and requiring
-very little (if any) platform specific code.
+{name} is the new and improved wxPython! This new implementation (known
+internally as "wxPython Phoenix") is focused on improving speed,
+maintainability and extensibility. Just like "Classic" wxPython it wraps the
+wxWidgets C++ toolkit and provides access to the user interface portions of
+the wxWidgets API, enabling Python applications to have a native GUI on
+Windows, Macs or Unix systems with a native look and feel and requiring very
+little (if any) platform specific code.
 
 For more information please refer to the
-`README.rst <https://github.com/wxWidgets/Phoenix/blob/master/README.rst>`_
-or the `wxPython documentation <https://wxpython.org/Phoenix/docs/html/>`_.
-"""
+`README file <https://github.com/wxWidgets/Phoenix/blob/master/README.rst>`_,
+the `Migration Guide <https://wxpython.org/Phoenix/docs/html/MigrationGuide.html>`_,
+or the `wxPython API documentation <https://wxpython.org/Phoenix/docs/html/main.html>`_.
+""".format(name=NAME)
+
 # or maybe LONG_DESCRIPTION=open("README.rst").read() ??
 
+if version.VER_FLAGS:
+    LONG_DESCRIPTION += """
+:note: To install  pre-release versions don't forget to add the ``--pre`` flag 
+    to the ``pip install`` command.
+"""
+
 CLASSIFIERS      = """\
 Development Status :: 3 - Alpha
 Environment :: MacOS X :: Cocoa

src/pyevent.h

@@ -23,7 +23,7 @@
 // of the event instance.
 
 // NOTE: This class is intentionally not exposed to SIP as there is no
-// need for it in Python code. Intead we just tell SIP that the __*attr__
+// need for it in Python code. Instead we just tell SIP that the __*attr__
 // methods are in the event classes. (See wxPyEvent and wxPyCommandEvent
 // below and in etg/pyevent.py.)