Update example documentation of samplebinding / scriptableapplication

Update versions and build information.

Pick-to: 6.2
Change-Id: I82eb4b36e2357145f89bb640f2674deda6fe2253
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>

4 files changed, 43 insertions, 21 deletions

diff --git a/examples/samplebinding/doc/samplebinding.rst b/examples/samplebinding/doc/samplebinding.rst
index af2e917dc..417bae9b8 100644
--- a/examples/samplebinding/doc/samplebinding.rst
+++ b/examples/samplebinding/doc/samplebinding.rst
@@ -35,8 +35,9 @@ In contrast ``Truck`` does not define virtual methods and is treated as
 a *value type* (copy semantics).
 
 Because ``Truck`` is a value type and it stores a vector of ``Icecream``
-pointers, the rule of three has to be taken into account (implement the
-copy constructor, assignment operator, destructor).
+pointers, the rule of five has to be taken into account (implement the
+copy constructor, assignment operator, move constructor, move assignment
+operator and destructor).
 
 And due to ``Icecream`` objects being copyable, the type has to define an
 implementation of the ``clone()`` method, to avoid type slicing issues.
@@ -144,7 +145,7 @@ The following requirements need to be met:
 * A PySide package is installed into the current active Python
   environment (system or virtualenv)
 
-* A new enough version of CMake (3.1+).
+* A new enough version of CMake (3.16+).
 
 * ninja
 
@@ -183,8 +184,6 @@ On Windows:
 
     mkdir build
     cd build
-    mkdir build
-    cd build
     cmake -H.. -B. -G Ninja -DCMAKE_BUILD_TYPE=Release
     ninja
     ninja install
@@ -207,6 +206,12 @@ by setting the ``CC`` environment variable:
 
     set CC=cl
 
+passing the compiler on the command line:
+
+.. code-block:: bash
+
+    cmake -H.. -B. -DCMAKE_C_COMPILER=cl.exe -DCMAKE_CXX_COMPILER=cl.exe
+
 or by using the -G option:
 
 .. code-block:: bash
@@ -215,7 +220,7 @@ or by using the -G option:
 
 If the ``-G "Visual Studio 14 Win64"`` option is used, a ``sln`` file
 will be generated, and can be used with ``MSBuild``
-instead of ``nmake/jom``.
+instead of ``ninja``.
 The easiest way to both build and install in this case, is to use
 the cmake executable:
 
@@ -223,7 +228,7 @@ the cmake executable:
 
     cmake --build . --target install --config Release
 
-Note that using the ``"NMake Makefiles JOM"`` generator is preferred to
+Note that using the ``"Ninja"`` generator is preferred to
 the MSBuild one, because the MSBuild one generates configs for both
 Debug and Release, and this might lead to building errors if you
 accidentally build the wrong config at least once.
@@ -258,12 +263,12 @@ In practice this means the only supported configurations are:
 
 #. release config build of the bindings +
    PySide ``setup.py`` without ``--debug`` flag + ``python.exe`` for the
-   PySide build process + ``python36.dll`` for the linked in shared
+   PySide build process + ``python39.dll`` for the linked in shared
    library.
 
 #. debug config build of the application +
    PySide ``setup.py`` *with* ``--debug`` flag + ``python_d.exe`` for the
-   PySide build process + ``python36_d.dll`` for the linked in shared
+   PySide build process + ``python39_d.dll`` for the linked in shared
    library.
 
 This is necessary because all the shared libraries in question have to
diff --git a/examples/samplebinding/truck.cpp b/examples/samplebinding/truck.cpp
index 056abfcd6..c8b0d8988 100644
--- a/examples/samplebinding/truck.cpp
+++ b/examples/samplebinding/truck.cpp
@@ -73,6 +73,10 @@ Truck &Truck::operator=(const Truck &other)
     return *this;
 }
 
+Truck::Truck(Truck &&other) = default;
+
+Truck& Truck::operator=(Truck &&other) = default;
+
 Truck::~Truck()
 {
     if (m_leaveOnDestruction)
diff --git a/examples/samplebinding/truck.h b/examples/samplebinding/truck.h
index 3f213f9ac..742b232eb 100644
--- a/examples/samplebinding/truck.h
+++ b/examples/samplebinding/truck.h
@@ -61,6 +61,9 @@ public:
     Truck(bool leaveOnDestruction = false);
     Truck(const Truck &other);
     Truck& operator=(const Truck &other);
+    Truck(Truck &&other);
+    Truck& operator=(Truck &&other);
+
     ~Truck();
 
     void addIcecreamFlavor(Icecream *icecream);
diff --git a/examples/scriptableapplication/doc/scriptableapplication.rst b/examples/scriptableapplication/doc/scriptableapplication.rst
index 46a29bd2f..b00d65415 100644
--- a/examples/scriptableapplication/doc/scriptableapplication.rst
+++ b/examples/scriptableapplication/doc/scriptableapplication.rst
@@ -51,10 +51,8 @@ For Windows you will also need:
 * Make sure that your Qt + Python + PySide package + app build configuration
   is the same (all Release, which is more likely, or all Debug).
 
-* Make sure that your Qt + Python + PySide package + app are built with the
-  same version of MSVC, to avoid mixing of C++ runtime libraries.
-  In principle this means that if you use the python.org provided Python
-  interpreters, you need to use MSVC2015 for Python 3 projects.
+* Make sure that your Qt + Python + PySide package + app are built with a
+  compatible version of MSVC, to avoid mixing of C++ runtime libraries.
 
 Both build options will use the ``pyside_config.py`` file to configure the project
 using the current PySide/Shiboken installation (for qmake via ``pyside.pri``,
@@ -64,7 +62,7 @@ and for CMake via the project ``CMakeLists.txt``).
 Using CMake
 +++++++++++
 
-To build this example with CMake you will need a recent version of CMake (3.1+).
+To build this example with CMake you will need a recent version of CMake (3.16+).
 
 You can build this example by executing the following commands
 (slightly adapted to your file system layout) in a terminal:
@@ -112,14 +110,26 @@ Windows troubleshooting
 Using ``qmake`` should work out of the box, there was a known issue
 with directories and white spaces that is solved by using the
 "~1" character, so the path will change from:
-``c:\Program Files\Python34\libs``
+``c:\Program Files\Python39\libs``
 to
-``c:\Progra~1\Python34\libs``
+``c:\Progra~1\Python39\libs``
 this will avoid the issues when the Makefiles are generated.
 
 It is possible when using ``CMake`` to pick up the wrong compiler
 for a different architecture, but it can be addressed explicitly
-using the -G option:
+by setting the ``CC`` environment variable:
+
+.. code-block:: bash
+
+    set CC=cl
+
+passing the compiler on the command line:
+
+.. code-block:: bash
+
+    cmake -H.. -B. -DCMAKE_C_COMPILER=cl.exe -DCMAKE_CXX_COMPILER=cl.exe
+
+or using the -G option:
 
 .. code-block:: bash
 
@@ -128,13 +138,13 @@ using the -G option:
 
 If the ``-G "Visual Studio 14 Win64"`` option is used, a ``sln`` file
 will be generated, and can be used with ``MSBuild``
-instead of ``nmake/jom``.
+instead of ``ninja``.
 
 .. code-block:: bash
 
     MSBuild scriptableapplication.sln "/p:Configuration=Release"
 
-Note that using the "NMake Makefiles JOM" generator is preferred to
+Note that using the "Ninja" generator is preferred to
 the MSBuild one, because in the latter case the executable is placed
 into a directory other than the one that contains the dependency
 dlls (shiboken, pyside). This leads to execution problems if the
@@ -171,11 +181,11 @@ In practice this means the only supported configurations are:
 
 #. release config build of the application +
    PySide ``setup.py`` without ``--debug`` flag + ``python.exe`` for the
-   PySide build process + ``python36.dll`` for the linked in shared
+   PySide build process + ``python39.dll`` for the linked in shared
    library + release build of Qt.
 #. debug config build of the application +
    PySide ``setup.py`` *with* ``--debug`` flag + ``python_d.exe`` for the
-   PySide build process + ``python36_d.dll`` for the linked in shared
+   PySide build process + ``python39_d.dll`` for the linked in shared
    library + debug build of Qt.
 
 This is necessary because all the shared libraries in question have to