• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..11-Nov-2020-

README.mdH A D11-Nov-20206 KiB171135

main.cppH A D11-Nov-20202.8 KiB6512

mainwindow.cppH A D11-Nov-20205.7 KiB14377

mainwindow.hH A D11-Nov-20202.8 KiB7718

pyside2.priH A D11-Nov-20202.6 KiB5337

pythonutils.cppH A D11-Nov-20206.2 KiB193109

pythonutils.hH A D11-Nov-20202.9 KiB8222

scriptableapplication.proH A D11-Nov-20203.3 KiB8668

scriptableapplication.xmlH A D11-Nov-20202.6 KiB575

wrappedclasses.hH A D11-Nov-20202.5 KiB574

README.md

1# Scriptable Application
2
3This example demonstrates how to make a Qt C++ application scriptable.
4
5It has a class **MainWindow** (`mainwindow.{cpp,h}`)
6that inherits from *QMainWindow*, for which bindings are generated
7using Shiboken.
8
9The header `wrappedclasses.h` is passed to Shiboken which generates
10class wrappers and headers in a sub directory called **AppLib/**
11which are linked to the application.
12
13The files `pythonutils.{cpp,h}` contain some code which binds the
14instance of **MainWindow** to a variable called **'mainWindow'** in
15the global Python namespace (`__main___`).
16It is then possible to run Python script snippets like:
17
18```python
19mainWindow.testFunction1()
20```
21which trigger the underlying C++ function.
22
23## Building the project
24
25This example can be built using *CMake* or *QMake*,
26but there are common requirements that you need to take into
27consideration:
28
29* Make sure that a --standalone PySide2 package (bundled with Qt libraries)
30  is installed into the current active Python environment
31  (system or virtualenv)
32* qmake has to be in your PATH:
33  * so that CMake find_package(Qt5) works (used for include headers),
34  * used for building the application with qmake instead of CMake
35* use the same Qt version for building the example application, as was used
36  for building PySide2, this is to ensure binary compatibility between the
37  newly generated bindings libraries, the PySide2 libraries and the
38  Qt libraries.
39
40For Windows you will also need:
41* a Visual Studio environment to be active in your terminal
42* Correct visual studio architecture chosen (32 vs 64 bit)
43* Make sure that your Qt + Python + PySide2 package + app build configuration
44  is the same (all Release, which is more likely, or all Debug).
45* Make sure that your Qt + Python + PySide2 package + app are built with the
46  same version of MSVC, to avoid mixing of C++ runtime libraries.
47  In principle this means that if you use the python.org provided Python
48  interpreters, you need to use MSVC2015 for Python 3 projects, and MSVC2008
49  for Python 2 projects. Which also means that you can't use official Qt
50  packages, because none of the supported ones are built with MSVC2008.
51
52Both build options will use the `pyside2_config.py` file to configure the project
53using the current PySide2/Shiboken2 installation (for qmake via pyside2.pri,
54and for CMake via the project CMakeLists.txt).
55
56
57### Using CMake
58
59To build this example with CMake you will need a recent version of CMake (3.1+).
60
61You can build this example by executing the following commands
62(slightly adapted to your file system layout) in a terminal:
63
64On macOS/Linux:
65```bash
66cd ~/pyside-setup/examples/scriptableapplication
67mkdir build
68cd build
69cmake -H.. -B. -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release
70make
71./scriptableapplication
72```
73
74On Windows:
75```bash
76cd C:\pyside-setup\examples\scriptableapplication
77mkdir build
78cd build
79cmake -H.. -B. -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release
80# or if you have jom available
81# cmake -H.. -B. -G "NMake Makefiles JOM" -DCMAKE_BUILD_TYPE=Release
82nmake # or jom
83scriptableapplication.exe
84```
85
86### Using QMake
87
88The file `scriptableapplication.pro` is the project file associated
89to the example when using qmake.
90
91You can build this example by executing:
92```bash
93mkdir build
94cd build
95qmake ..
96make # or nmake / jom for Windows
97```
98
99#### Windows troubleshooting
100
101Using **qmake** should work out of the box, there was a known issue
102with directories and white spaces that is solved by using the
103"~1" character, so the path will change from:
104c:\Program Files\Python34\libs
105to
106c:\Progra~1\Python34\libs
107this will avoid the issues when the Makefiles are generated.
108
109It is possible when using **cmake** to pick up the wrong compiler
110for a different architecture, but it can be addressed explicitly
111using the -G option:
112
113```bash
114cmake -H.. -B. -G "Visual Studio 14 Win64" -DCMAKE_BUILD_TYPE=Release
115```
116
117If the `-G "Visual Studio 14 Win64"` option is used, a `sln` file
118will be generated, and can be used with `MSBuild`
119instead of `nmake/jom`.
120
121```bash
122MSBuild scriptableapplication.sln "/p:Configuration=Release"
123```
124
125Note that using the "NMake Makefiles JOM" generator is preferred to
126the MSBuild one, because in the latter case the executable is placed
127into a directory other than the one that contains the dependency
128dlls (shiboken, pyside). This leads to execution problems if the
129application is started within the Release subdirectory and not the
130one containing the dependencies.
131
132## Virtualenv Support
133
134If the application is started from a terminal with an activated python
135virtual environment, that environment's packages will be used for the
136python module import process.
137In this case, make sure that the application was built while the
138`virtualenv` was active, so that the build system picks up the correct
139python shared library and PySide2 package.
140
141## Linux Shared Libraries Notes
142
143For this example's purpose, we link against the absolute paths of the
144shared libraries (`libshiboken` and `libpyside`) because the
145installation of the modules is being done via wheels, and there is
146no clean solution to include symbolic links in the package
147(so that regular -lshiboken works).
148
149## Windows Notes
150
151The build config of the application (Debug or Release) should match
152the PySide2 build config, otherwise the application will not properly
153work.
154
155In practice this means the only supported configurations are:
156
1571. release config build of the application +
158   PySide2 `setup.py` without `--debug` flag + `python.exe` for the
159   PySide2 build process + `python36.dll` for the linked in shared
160   library + release build of Qt.
1612. debug config build of the application +
162   PySide2 `setup.py` **with** `--debug` flag + `python_d.exe` for the
163   PySide2 build process + `python36_d.dll` for the linked in shared
164   library + debug build of Qt.
165
166This is necessary because all the shared libraries in question have to
167link to the same C++ runtime library (`msvcrt.dll` or `msvcrtd.dll`).
168To make the example as self-contained as possible, the shared libraries
169in use (`pyside2.dll`, `shiboken2.dll`) are hard-linked into the build
170folder of the application.
171