Comments 43
Эх, даже жалко иногда, что нечего программировать сейчас на Qt'e, ни по работе, ни как хобби, ведь одно удовольствие!
Вкратце, вот скрин из прошедшего вебинара (видео можно загрузить, пожертвовав какие-нибудь данные мерзкому Хабспоту) по грядущим изменениям в Qt Quick:
На словах докладчик сказал, что "МОЖЕТ БЫТЬ, в Qt 5.10".
Также он говорил, что вопрос этот задают очень часто, но не всегда ясно, что именно входит в понятие "поддержка Vulkan", потому что это может означать несколько вещей, например рендер Vulkan-контента в окно, или поддержка Vulkan в QPainter, или поддержка Vulkan в Qt Quick Scene Graph, или что-то совсем иное.
Кстати с Qt — работаю с 2002 года, и помню какие положительные эмоции были в сыходом 4.2, 4.4, 4.5.
Был такой крутой технический прогресс.
Да, поддержка была заявлена. Но не в том плане, что будут какие-то дополнительные инструменты для этого.
Qt Lite лишь означает больше возможностей по конфигурации/оптимизации Qt (теперь можно выкинуть ещё больше компонентов), что снижает требования к памяти до значений, с которыми можно работать на M7. Уже есть примеры реализации, включая GUI на девайсе, реализованные сторонними сервисными компаниями в качестве "proof-of-concept". Я хотел найти живое демо у нас в офисе, но ни у кого не оказалось.
Если я правильно понял вопрос, то готовые образы Boot to Qt, тулчейны для кросс-компиляции и прочее такое входит в продукт Device Creation, а он доступен только в коммерческой лицензии. Чтобы не покупать кота в мешке, есть триальная версия на месяц.
Но кстати да, идёт работа над лицензиями для университетов, Device Creation в неё тоже будет входить. Только это ещё не совсем публичная информация, потому пока без подробностей.
Это есть в планах, но настолько далёких и неопределённых, что в обозримый roadmap включать не стали.
Текущий статус вкратце: можно было бы реализовать QtScript API и для QJSEngine, это самое быстрое решение, но этого не будет, потому что проблема-то как раз была в том, что движок JS работал в том же треде, что и отладчик, и это было "ущербно на корню" (fundamentally flawed). Потому грядущая реализация отладки QJSEngine нацелена на то, чтобы скрипты работали в тредах, отдельных от треда Qt GUI, и это можно будет отлаживать с помощью отдельного API.
Очень надеюсь, что виджеты не будут заброшены, на мой взгляд, для десктопа это практически идеал — сочетание простоты и производительности.
Новые элементы 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.
Текущие бета-версии складываются здесь.
Обсуждение сейчас идёт в этом треде, можете присоединиться и обсудить совместую разработку.
Да, это будет. В реквесте последний комментарий как раз об этом: "Пока сделано в таком виде, но мы продолжаем работать, и к следующему релизу постараемся реализовать и поддержку предпросмотра".
виджеты считаются «устоявшейся» технологией, к тому же не очень подходящей для embedded платформ
Windows Compact Embedded 5.x c вами не согласен :)
QML приложения текут по памяти что на 4.8 что на 5.6. А с учетом ограничений по памяти на 32 мегабайта на процесс это очень грустно заканчивается через 10-15 экранов.
Если такие намерения и были раньше, то сейчас нет, потому что уже существует кроссплатформенная библиотека libusb, например, и неоправданно тратить ресурсы на реализацию того же самого внутри Qt, разумнее направить их на более востребованные фичи (и багфиксы).
Возможно, это более оправдано с точки зрения лицензирования — чтобы существовал "коммерческий" вариант компонента, свободный (каламбур) от LGPL. Но так или иначе, в текущих планах этого нет.
Кстати, подобный feature-request уже существует, так что если будет достаточное количество голосов/комментариев (а особенно от какой-нибудь крупной компании-клиента), возможно он получит более высокий приоритет.
Я, возможно, неправильно понял вопрос, но зачем вам две версии? Если ваше приложение под x64, то вам и нужна только сборка Qt под x64? Это вы про то что MinGW под Windows "из коробки" поставляется x32?
Согласен, что на уровне домашних поделок, студенческих поделок, и даже разовой работы на клиента две версии qt одновременно не нужно, это на личном опыте подтверждаю (один раз только клиенту потребовалась библиотека, которую я делал и под x86 и под x64, но там без Qt обошлось). А вот при работе с большими коммерческими продуктами в этом уже есть необходимость.
Тот же буст, например, пусть за 2 итерации, но можно собрать и x86 и x64 в разные stage но на одних исходниках, не надо в репозитории для third-party sdk 2 буста иметь.
Например, можно ли встроить в браузер проект из примеров Qml Oscilloscope на 60 FPS при максимальном количестве точек?
Те графики, которые используют QPainter, то есть рисуют граф и сохраняют его в текстуру, не будут работать. Другие — работают. Конкретно демо Oscilloscope тоже должно работать. Я попробую запустить или спрошу у разработчика модуля.
Кстати, Oscilloscope работает и в WebAssembly, вот тут в посте его упоминают.
Qt: Embedded World 2017 и roadmap