Разговаривал на QT Dev 2015 в Берлине с разработчиком WebEngine, услышал много вздохов и увидел много печали в глазах, но вменяемого ответа о том — зачем выпиливать отлично интегрированный Веб движек, прекрасно положенный в инфраструктуру Qt и используемый в очень большом количестве десктопных бизнес приложений и впиливать нечто даже функционально не всегда совместимое не услышал…
Сравните степень интеграции WebKit с поддержкой native QNetworkAcessManager, QNetworkRequest, QNetworkReply, полностью контролируемого и использующего стандартный для Qt транспортный уровень и сравните с текущим состоянием WebEngine… где ряд вещей просто технически пока не переносятся, вне зависимости от размера бубна…
По сути последние годы развития Qt это путь в мобильные платформы и понятно что сделать обертку на native webview для каждой из платформ в текущем виде WebEngine гораздо проще чем через интерфейсы WebView, но господа Qt-шники, мир крутится не только вокруг embedded и mobile и есть огромное количество enterprise приложений где новое не всегда лучше хорошо работающего старого…
На самом деле это очень спорное решение, вот здесь обсуждалось: forum.qt.io/topic/52306/qt-5-5-qt-script-deprecated-what-is-replacement, (к сожалению после того как Qt сделало merge аккаунтов, мои комментарии там стали просто под серым невидимкой =)), это заблуждение думать что QJSEngine везде и всегда заменяет легковесный и отлично интегрированный QtScript. Я применял его в проектах не имеющих ничего общего с QML начиная еще с Qt 3.* — там он был еще не не ECMA совместимый, но кстати тоже отлично читаемый с С++ подобным синтаксисом.
Не всегда и не везде есть/нужно тащить за собой V8 реализацию если просто требуется какую то несложную обвязку вынести «наружу» в скрипт.
Я приводил пример в этом топике, он отлично подходил, например для описывания правил фильтрации/сортировки в моделях, построенных на коллекциях QObject-ов…
Сравните степень интеграции WebKit с поддержкой native QNetworkAcessManager, QNetworkRequest, QNetworkReply, полностью контролируемого и использующего стандартный для Qt транспортный уровень и сравните с текущим состоянием WebEngine… где ряд вещей просто технически пока не переносятся, вне зависимости от размера бубна…
По сути последние годы развития Qt это путь в мобильные платформы и понятно что сделать обертку на native webview для каждой из платформ в текущем виде WebEngine гораздо проще чем через интерфейсы WebView, но господа Qt-шники, мир крутится не только вокруг embedded и mobile и есть огромное количество enterprise приложений где новое не всегда лучше хорошо работающего старого…
Не всегда и не везде есть/нужно тащить за собой V8 реализацию если просто требуется какую то несложную обвязку вынести «наружу» в скрипт.
Я приводил пример в этом топике, он отлично подходил, например для описывания правил фильтрации/сортировки в моделях, построенных на коллекциях QObject-ов…