Pull to refresh

Comments 43

QWebEngine под MinGW планируется или нет?

Вряд ли скажу что-то новое, но проблема заключается в поддержке (её отсутствии) MinGW в самом Chromium, потому вряд ли это случится раньше момента, когда команда Chromium её реализует.

Chromium на винде теперь можно собирать через clang и lld. Будет ли поддержка QWebEngine через clang/lld?

Для этого сначала должна появиться поддержка Clang для всего Qt под Windows, потому что не очень оправданно делать это только для WebEngine. Это тоже обсуждается, и скорее всего в какой-то момент появится, но конкретных сроков нет.

Спасибо большое за такую сводку — приходили письма на почту, но читать как-то некогда было, а тут все по полочкам и в одном месте.
Эх, даже жалко иногда, что нечего программировать сейчас на Qt'e, ни по работе, ни как хобби, ведь одно удовольствие!

Если честно, то меня от писем, которые рассылает наш маркетинг, немножко трясёт. Это, кстати, одна из причин, почему я захотел написать эту статью (и возможно последующие).

Наверное, весь маркетинг такой, за кем нет грешков? :)
Большое спасибо за статью, даже если хорошо знаешь английский, на русском читать как-то приятнее)

UFO just landed and posted this here

Вкратце, вот скрин из прошедшего вебинара (видео можно загрузить, пожертвовав какие-нибудь данные мерзкому Хабспоту) по грядущим изменениям в Qt Quick:


image


На словах докладчик сказал, что "МОЖЕТ БЫТЬ, в Qt 5.10".


Также он говорил, что вопрос этот задают очень часто, но не всегда ясно, что именно входит в понятие "поддержка Vulkan", потому что это может означать несколько вещей, например рендер Vulkan-контента в окно, или поддержка Vulkan в QPainter, или поддержка Vulkan в Qt Quick Scene Graph, или что-то совсем иное.

UFO just landed and posted this here
Суперкары и 3D это, безусловно, здорово.
Но, как можно видеть, предыдущий roadmap не выполнен.
Qt Bluetooth не работает в Windows, Bluetooth LE и вовсе не работает нигде за пределами *nix, поддержка Win 10 — не закончена, память подтекает и делать с этим никто ничего не хочет.

Девять лет уже пишу на Qt, и не могу сказать, что текущее направление развития мне нравится — фреймворк становится всё более фрагментарным, предоставляет всё больше плюшек и красивостей, теряя при этом в качестве. Судя по всему, придется скоро менять стек технологий.
Они стараются занять выгодные и доходные ниши. Сейчас это автомобильная электроника, в связи с прогрессом в области беспилотных авто, поэтому и QtQuick, рюшечки и прочие красивости.

Кстати с Qt — работаю с 2002 года, и помню какие положительные эмоции были в сыходом 4.2, 4.4, 4.5.
Был такой крутой технический прогресс.
Честно говоря после выхода 4.5 и перехода в этой версии на LGPL, многие думали, что Gtk умрёт. Ошиблись…
Меня интересуют вопрос по embedded, в частность было объявлено, что с приходом qt lite будет поддержка cortex M7, если у же такая возможность?, если нет, то когда будет, что будет из себя представлять, какой будет функционал?

Да, поддержка была заявлена. Но не в том плане, что будут какие-то дополнительные инструменты для этого.


Qt Lite лишь означает больше возможностей по конфигурации/оптимизации Qt (теперь можно выкинуть ещё больше компонентов), что снижает требования к памяти до значений, с которыми можно работать на M7. Уже есть примеры реализации, включая GUI на девайсе, реализованные сторонними сервисными компаниями в качестве "proof-of-concept". Я хотел найти живое демо у нас в офисе, но ни у кого не оказалось.

Device Creation для «энтузиастов» будет?

Если я правильно понял вопрос, то готовые образы Boot to Qt, тулчейны для кросс-компиляции и прочее такое входит в продукт Device Creation, а он доступен только в коммерческой лицензии. Чтобы не покупать кота в мешке, есть триальная версия на месяц.


Но кстати да, идёт работа над лицензиями для университетов, Device Creation в неё тоже будет входить. Только это ещё не совсем публичная информация, потому пока без подробностей.

Вот бы еще гуру реализовали пример отладчика для QJSEngine скриптов. QJSEngine шустрее, чем старый добрый QtScript, но отсутствие аналогичного примера или хотя бы документации на эту тему, снижает удобство применения.

Это есть в планах, но настолько далёких и неопределённых, что в обозримый roadmap включать не стали.


Текущий статус вкратце: можно было бы реализовать QtScript API и для QJSEngine, это самое быстрое решение, но этого не будет, потому что проблема-то как раз была в том, что движок JS работал в том же треде, что и отладчик, и это было "ущербно на корню" (fundamentally flawed). Потому грядущая реализация отладки QJSEngine нацелена на то, чтобы скрипты работали в тредах, отдельных от треда Qt GUI, и это можно будет отлаживать с помощью отдельного API.

Спасибо за пояснения. Мне почему-то казалось, что отладка скриптов в том или ином виде уже существует, раз Qt Creator умеет отлаживать QML приложения. Думал, в основе QJSEngine какая-то разновидность движка V8, а к последнему вроде есть внешние отладчики и документация, но увы, «подключить» не получилось.
Спасибо!
Очень надеюсь, что виджеты не будут заброшены, на мой взгляд, для десктопа это практически идеал — сочетание простоты и производительности.
Новые элементы Qt Quick Controls: во-первых, уже достаточно давно обещанный TableView

Когда ожидается?

В списке нового функционала Qt 5.9 его нет, значит не раньше Qt 5.10. Как пишет ведущий разработчик Qt Quick Controls: "… задача большая, мы работаем".


А эта ссылка вам, скорее всего, уже известна: https://bugreports.qt.io/browse/QTBUG-51710. Все обновления будут там.

Спасибо, подписался, буду следить
Здравствуйте.
Не уверен, что по адресу, но как дела относительно поддержки VS2017 у Qt Visual Studio Tools?
Я создатель пакета, который долгое время служил заменой официальному(его выпускали более двух лет), и на данный момент мне пишет много людей с просьбой обновить пакет. Сейчас основная работа у меня проходит на C#, и у меня, к сожалению, не хватает времени для этого. В идеале, следовало бы совместить мои наработки с официальной версией, но проблема все та же.
Если сроки, как и в прошлый раз, не известны, я все таки могу это сделать. Просто дайте знать.

Соответствующий реквест уже закрыт. Да и вообще, должно "просто работать", то есть можно взять версию для VS2015 и поставить в VS2017, так как они ABI-compatible.


Текущие бета-версии складываются здесь.


Обсуждение сейчас идёт в этом треде, можете присоединиться и обсудить совместую разработку.

Спасибо за статью. Отличное начинание, ждем еще большего количества информации изнутри The Qt Company))
Скажите, не планируется ли подружить QWebEngine и QPrintPreviewDialog? В 5.8 печать из QWebEngine сделали, но она идёт через «виртуальный pdf», и на QPrintPreviewDialog ничего не отображается. Я конечно написал свой диалог предпросмотра, но он по сравнению с тем что есть в Qt, гораздо менее функционален. Просто не очень приятно, когда обновляют компонент, и часть стабильного функционала перестаёт работать.

Да, это будет. В реквесте последний комментарий как раз об этом: "Пока сделано в таком виде, но мы продолжаем работать, и к следующему релизу постараемся реализовать и поддержку предпросмотра".

виджеты считаются «устоявшейся» технологией, к тому же не очень подходящей для embedded платформ

Windows Compact Embedded 5.x c вами не согласен :)
QML приложения текут по памяти что на 4.8 что на 5.6. А с учетом ограничений по памяти на 32 мегабайта на процесс это очень грустно заканчивается через 10-15 экранов.
Будет ли реализована поддержка USB средствами Qt наподобие QSerialPort?

Если такие намерения и были раньше, то сейчас нет, потому что уже существует кроссплатформенная библиотека libusb, например, и неоправданно тратить ресурсы на реализацию того же самого внутри Qt, разумнее направить их на более востребованные фичи (и багфиксы).


Возможно, это более оправдано с точки зрения лицензирования — чтобы существовал "коммерческий" вариант компонента, свободный (каламбур) от LGPL. Но так или иначе, в текущих планах этого нет.


Кстати, подобный feature-request уже существует, так что если будет достаточное количество голосов/комментариев (а особенно от какой-нибудь крупной компании-клиента), возможно он получит более высокий приоритет.

Вопрос: не планируется ли наконец сделать, чтобы можно было собрать qt сразу одновременно и под x86 и под x64? Надоело уже держать 2 версии qt для этого. Проблема ещё в том, что приходится патчи и туда и туда заливать, иногда забываешь…

Я, возможно, неправильно понял вопрос, но зачем вам две версии? Если ваше приложение под x64, то вам и нужна только сборка Qt под x64? Это вы про то что MinGW под Windows "из коробки" поставляется x32?

Объясняю. Есть N продуктов. Пусть даже и связанных. Но часть идёт как x86 онли (старое), часть как и x86, так и x64 (потребности по памяти в x64). А что-то, например, утилиты некоторые, вообще нужны под x64 из-за своих особенностей. + некоторые либы сторонние есть только x64 (тот же Caffe) поэтому даже во вроде бы полностью x86 продуктах, приходится делать отдельные приложения, которые работают под x64.
Согласен, что на уровне домашних поделок, студенческих поделок, и даже разовой работы на клиента две версии qt одновременно не нужно, это на личном опыте подтверждаю (один раз только клиенту потребовалась библиотека, которую я делал и под x86 и под x64, но там без Qt обошлось). А вот при работе с большими коммерческими продуктами в этом уже есть необходимость.
Тот же буст, например, пусть за 2 итерации, но можно собрать и x86 и x64 в разные stage но на одних исходниках, не надо в репозитории для third-party sdk 2 буста иметь.
Qt Charts + WebGL streaming — насколько подъемная вещь?
Например, можно ли встроить в браузер проект из примеров Qml Oscilloscope на 60 FPS при максимальном количестве точек?

Те графики, которые используют QPainter, то есть рисуют граф и сохраняют его в текстуру, не будут работать. Другие — работают. Конкретно демо Oscilloscope тоже должно работать. Я попробую запустить или спрошу у разработчика модуля.


Кстати, Oscilloscope работает и в WebAssembly, вот тут в посте его упоминают.

Интересует в основном производительность рендеринга меняющейся картинки. Например, отрисовка графиков с быстро меняющимися данными (десяток временных рядов + скролл)?

Ну, вместо примерных цифр на отдельно взятой конфигурации рекомендую запустить и посмотреть :)
Исходники открыты, требования GPL для "попробовать" не обременительны.

Конкретно демо Oscilloscope тоже должно работать
Я попробую запустить

… проверил — работает.

Sign up to leave a comment.

Articles