It is important to note that with QT5.6, the QWebView support has been dropped in favour of the Chromium-based QWebEngine. The two offer similar functionality, although there are some differences (asynchronicity of responses being a major one).
QWebEngine's use of Chromium means that the development tools for Windows must use Visual Studio - 2013 or 2015 (at the time of writing).
This means that the QT development using MinGW is incompatible - if you try to build an application with QWebEngineWidgets, you are simply told it does not exist.
Building Options
Option 1: Virtual Machine
This option requires you to install windows (version 7 or greater) in a virtual machine, on which is installed: Visual Studio Community 2013.5 and QT 5.6 for visual studio.
Any time you wish ot build a Windows application, you need to launch the virtual machine.
You can build from the command line with qmake and nmake. You can also build from the QTCreator environement with correctly configured kits, and I also believe, from the visual studio environment.
Installation of the resulting executable is achieved by:
Copying the .exe file to a chosen folder
Running windeployqt.exe to also transfer the required DLLs and support files
Installing the copied files on the target machine
Installing the Visual Studio 2013.5 runtime on the target machine
Option 2: Wine - MinGW
This has not been tried - yet.
Option 3: Wine - Visual Studio 2013.5
This fails pretty quickly, as it is not possible to install even the visual studio 2013.5 runtime on Wine.
There is an attempt to create a tool distribution on Wine, but this requires you to go much of the way through Option 1, above, so has little advantage.
Option 4: Crossover - MinGW
This works fine - you can install QT Creator and associated MinGW libraries, buid and execute applications. However, MinGW is not supported by the Chromium project, so you can't produce applications using QWebEngine.
Option 5: Crossover - Visual Studio 2013.5
Crossover has better support - you can install the runtime on crossover in a bottle, and applications you have compiled (in option 1) actually run applications, although I have found that QWebEngine applications crash when you invoke the web-engine (i.e. populate / display a web page).
However, although the QT development tools install OK, the Visual Studio tools refuse to install, so whilst you can run applications with the Visual Studio runtime, you can't compile them!
Conclusions
Virtual Machine: [build-ok] [buildwebengine-ok] [run-ok] [runwebengine-ok]
Wine - MinGW: [build-?] [buildwebengine-fail] [run-?] [runwebengine-fail]
Wine - Visual Studio: [build-fail] [buildwebengine-fail] [run-fail] [runwebengine-fail]
Crossover - MinGW: [build-ok] [buildwebengine-fail] [run-ok] [runwebengine-fail]
Crossover - Visual Studio: [build-fail] [buildwebengine-fail] [run-ok] [runwebengine-fail]
build - Applications can be built using QTCreator or command line (with appropriate visual studio or MinGW compiler)
buildwebengine - WebEngine Applications can be built using QTCreator or command line
run - Applications run OK on the platform
runwebengine - WebEngine Applications run OK on the platform
So, if you are looking to produce applications which use WebEngine, a virtual machine is currently the only real way to go.
If you are looking to produce non WebEngine applications, using MinGW may be right - this does work with Crossover, and may work with Wine.
Caveat: Note that I have used WebEngine as an example of how Visual Studio and MinGW produced applications differ. In the past (QT4) I have found that they also differ in the way they support accessibility, and there may well be other differences.
So, if you are looking to produce applications which use WebEngine, a virtual machine is currently the only real way to go.
If you are looking to produce non WebEngine applications, using MinGW may be right - this does work with Crossover, and may work with Wine.
Caveat: Note that I have used WebEngine as an example of how Visual Studio and MinGW produced applications differ. In the past (QT4) I have found that they also differ in the way they support accessibility, and there may well be other differences.
No comments:
Post a Comment