+ , QtWebEngine is by far the most brittle, difficult dependency to build, and it’s also the largest single library after SimpleITK (which could potentially be made smaller with some linking changes, I think).
(if anyone is hacking on this, a huge initial improvement would be to just make QtWebEngine optional – the benefit is very limited for local builds, which cannot really use the extension manager anyway. I believe the other main use is the old jquery plotting system, but that could be disabled too)
That’s replaced by the much faster and more flexible table node based plotting infrastructure. We can deprecate the old jquery based method anytime (probably we can do it after releasing 4.10).
For Windows builds, Qt 5.11 updated QtWebEngine to use Chromium 65 which requires Visual Studio 2017 to build (QtWebEngine platform notes and Chromium build instructions). If downloading the Qt5 binary using the Qt Maintenance Tool, QtWebEngine will only be downloaded if you choose the MSVC 2017 64-bit option.
If Slicer is going to keep using QtWebEngine, Slicer will need to restrict using Qt >5.11 if building QtWebEngine dependencies, or officially support Windows builds using MSVC 2017.
Qt 5.12 should be released by the end of November and will be a LTS release. Might make sense to prepare for 5.12 by building Windows builds with MSVC 2017. It honestly will be a little more user friendly for people who aren’t frequent source builders since Visual Studio 2015 community doesn’t have a publicly available download anymore and you have to use Visual Studio 2017 w/v140 package and specify the v140 toolset during configuration.
After we release Slicer-4.10 we plan to use the same Visual Studio version that is used for building official Python packages so that we can install binary packages directly. Currently, Python 3.5 and 3.6 uses VS2015 and Python 3.6 and 3.7 can use VS2017. So, we can jump to Python 3.6 + Qt 5.11 (with QtWebEngine).
However, due to problems listed above (size, difficulty to build, offering different look&feel and somewhat limited interface with the application), it would be still nice to get rid of QtWebEngine.
For the near term it does appear that QtWebEngine is causing more trouble than it’s worth, given the limited number of places it’s currently used. As we discussed on the last dev call it there is some work required to work around it and turn off the dependency.
Longer term we can keep an eye on how things evolve. If it becomes a seamless first class part of Qt, then having a consistent and controllable cross-platform web infrastructure could be really powerful.
, QtWebEngine is by far the most brittle, difficult dependency to build, and it’s also the largest single library after SimpleITK (which could potentially be made smaller with some linking changes, I think).