Новости Qt, май 2018 — декабрь 2018

    Очередной сборник новостей Qt, на этот раз за последние полгода с прошлой статьи. Релизы 5.11 и 5.12, реинкарнация PySide, внезапные похороны Qbs, выход Qt Design Studio и значительное улучшение условий лицензий для стартапов.


    ДДПВ


    Интересной КПДВ я не придумал, потому вместо неё просто ДДПВ — это к нам летом в офис приходил фотограф на корпоративную фотосессию, из которой я и подрезал фотку коллеги.


    Начнём с нарушенных обещаний. В конце предыдущей статьи были размещены два голосования: за перевод поста из официального блога про портирование Qt на микроконтроллеры и за написание обзора Safe Renderer, и голосование показало, что обе статьи заслуживают публикации. Но в размещении микроконтроллерной статьи НЛО автору отказало: "Публикации рекламного характера вне корпоративного блога и хаба «Я пиарюсь» запрещены правилами сайта". Сложно сказать, что именно там было рекламного (можете посмотреть английский оригинал и оценить), но в таком случае про Safe Renderer не было даже и смысла пытаться (потому что это исключительно коммерческая фича). Так что простите, если кто ждал.


    Содержание на сегодня:



    Новые релизы


    Qt 5.11


    22 мая вышел Qt 5.11.


    Не могу выделить какие-то особо значительные нововведения, кроме переработанного процесса компиляции QML, который должен существенно улучшить производительность Qt Quick приложений:


    QML compiler pipeline


    Также в релизе:


    • поддержка High-DPI для Qt Widgets на Windows (до этого было только в Mac OS и Linux);
    • поддержка сжатых текстур в Qt Quick;
    • превью реализации коммуникационного протокола OPC UA;
    • превью Qt for WebAssembly. Но зачем.

    Qt 5.12


    6 декабря вышел Qt 5.12 (обзор от CTO), очередной LTS релиз, который будет поддерживаться 3 года.


    Улучшена производительность. В основном это касается движка QML и JavaScript, который теперь соответствует стандарту ECMAScript 7.


    Релиз Qt Remote Object — механизма межпроцессорного взаимодействия как на одном хосте, так и между разными хостами по сети.


    Релиз Qt Quick WebGL, он же Qt WebGL streaming — то есть возможность транслировать GUI приложения, работающего на удалённом хосте (устройстве без дисплея), и отображать его в браузере на десктопе или планшете. Как пример — Raspberry Pi с камерой, Qt-приложение стримит GUI вместе с выводом камеры, а рендерится всё в обычном Safari на iPad:


    Qt Quick WebGL


    Очень прикольная штука, я прямо восторгом с ней поигрался, но откровенно говоря я не представляю, кто и зачем будет этим пользоваться. Если и так подразумевается работа с девайсом из браузера, то зачем городить GUI на Qt Quick и стримить его в WebGL? Не проще ли тогда просто запустить на девайсе нормальный веб-сервер, а GUI на клиенте будет с HTML/CSS/JS без вот этого всего? Странная фича, в общем.


    В Qt Quick Controls 2 наконец-то добавили TableView. Вот даже сравнение производительности аналога из Qt Quick Controls 1. К сожалению, по-прежнему никаких новостей про TreeView.


    Pointer Handlers вышли из статуса превью и переименовались в Input Handlers. Это новый модуль для обработки ввода с мыши, клавиатуры и тачскрина. В связи с этим в какой-то момент следует ожидать "устаревания" MouseArea.


    В Qt Virtual Keyboard помимо прочего добавлены новые языки а также новый движок рукописного ввода — MyScript.


    В Qt for Device Creation появились так называемые Qt Board Support Packages. Это те же самые Yocto образы и тулчейны, только теперь в виде отдельно загружаемых и подключаемых к установщику пакетов. Смысл QBSP заключается в поддержке партнёров-вендоров железа, чтобы им было удобнее создавать и распространять Boot to Qt образы для своих устройств.


    Развивается поддержка Wayland.


    Обновления инструментов


    Qt Creator


    За полгода вышло две версии Qt Creator: 4.7 и 4.8.


    Из наиболее значимых нововведений — поддержка Language Server Protocol, то есть возможность расширения Qt Creator для работы с большим количеством языков программирования. В то же время, "родной" QML до сих пор не в курсе последних версий модулей для импорта, из-за чего их приходится перебирать научным тыком.


    В версии 4.8 также должен был быть добавлен модуль телеметрии, но в этот релиз он не попал, так что ожидайте в 4.9.


    Qt Design Studio


    Тот самый полусекретный проект:



    Как вы знаете, в составе Qt есть прекрасный инструмент для создания GUI на Widgets — Qt Designer. С ним можно работать как из Qt Creator (вкладка Design), так и запустив его как самостоятельное приложение для работы с .iu файлами.


    С появлением Qt Quick добавился инструмент Qt Quick Designer, который уже нельзя запустить как отдельное приложение, так как он насмерть прибит гвоздями к Qt Creator.


    И вот Qt Design Studio — это тот же самый Qt Quick Designer, но с дополнительным функционалом. Также это теперь самостоятельное приложение, хотя по факту это просто покалеченная копия Qt Creator, которая запускается сразу в режиме дизайна Qt Quick (с возможностью переключения в режим редактирования QML).



    Из нового функционала: линия времени для работы с анимациями, удобные диалоги для настройки этих анимаций и компонент live-preview для предпросмотра изменений на лету как в отдельном окне, так и на присоединённом планшете или другом устройстве. Примечательно, что все эти вещи вряд ли когда-нибудь попадут обратно в Qt Quick Designer.


    Qt Design Studio предназначена для дизайнеров, и подразумевается, что они будут создавать в ней дизайн приложения, передавать результат (.ui.qml файлы) разработчикам, а разработчики будут работать с ними в полноценном Qt Creator.


    Также ведётся разработка плагинов для существующих популярных инструментов дизайна, чтобы дизайнеры могли экспортировать свои наработки из этих инструментов в QML. Первым был создан плагин для Adobe Photoshop, следующим ожидается плагин для Sketch, затем Adobe XD и другие.


    Я не дизайнер, потому мне сложно оценить полезность Qt Design Studio. Когда в Qt были только Widgets, я с плохо скрываемым удовольствием работал в Qt Designer, это отличный инструмент для создания GUI и по сей день. Когда появился Qt Quick, я несколько раз пытался пользоваться Qt Quick Designer, но в итоге бросил и просто пишу QML, для меня так удобнее и быстрее. А так как Qt Design Studio это почти что и есть Qt Quick Designer, то лично я ей пользоваться буду вряд ли. В то же время, насколько мне известно, ряд дизайнерских агентств, которые получили Qt Design Studio на "тест-драйв", отзываются о ней положительно.


    В плане лицензирования инструмент вроде как заявлен в Open Source (GPLv3), но в то же время вроде как для распространения результатов работы требуется коммерческая лицензия. Да и просто загрузить установщик не так-то просто, требуется наличие Qt Account. В общем, менеджеры продукта пока ещё не совсем определились.


    Qt 3D Studio


    Продолжается развитие Qt 3D Studio. За это время вышли версии 2.0 (более подробный обзор), 2.1 и 2.2.


    Наиболее значительно изменение — переход с движка оригинальной NVIDIA DRIVE Design Studio на собственный движок на основе Qt 3D и значительное улучшение производительности.


    Также был обозначен план объединения Qt 3D Studio и Qt Design Studio в единый инструмент, то есть вместо двух это будет одно приложение для работы с 2D и 3D.


    Анонс Kuesa


    Говоря о 3D, тут KDAB выпустили своё решение для работы с 3D — Kuesa.


    В отличие от Qt 3D Studio, они не стали тратить ресурсы на собственный инструмент для 3D моделирования, а позволяют дизайнерам работать с их привычными инструментами (3DS Max, Blender), и далее разработчик может использовать экспортированные glTF модели в Qt. Для удобства в наличии также есть приложение для предпросмотра модели и наименований компонентов, чтобы разработчик знал как к ним обращаться у себя в коде, не открывая модель в оригинальном 3D редакторе.


    На мой взгляд Kuesa является конкурирующим Qt 3D Studio решением (и судя по всему, более удачным), и это досадно, потому что вместо того, чтобы параллельно заниматься одним и тем же, эти усилия можно было бы потратить на что-то более полезное (я сейчас не обязательно про KDAB). Тут кстати будет напомнить что сам Qt 3D это тоже вклад KDAB.


    Релиз PySide2 / Qt for Python


    PySide вернулся, переименовался сначала в PySide2, а потом в скучный Qt for Python.


    Первый релиз вышел с Qt 5.11, но он всё ещё не считался за полноценный, а вот буквально на днях выпустили уже официальный релиз вместе с Qt 5.12.


    Вряд ли я могу рассказать здесь что-то новое. Как и раньше, PySide — это возможность использовать Qt (в основном, для GUI) из Python. Распространяется через PyPI, то есть в состав официального установщика Qt не входит, и устанавливается отдельно через pip. Поддержка на embedded платформах пока отсутствует, хотя и запланирована.


    Списка отличий от PyQt нет, хотя разработчики и заверяют, что PySide почти ни в чём не уступает, а скоро будет ещё и превосходить. С точки зрения коммерческого лицензирования, с PySide "всё включено" в стоимость лицензии Qt без дополнительной платы, а с PyQt надо ещё платить в Riverbank; с точки зрения Open Source, PySide доступен как под GPLv3, так и под LGPLv3, в то время как PyQt доступен только под GPLv3.


    Дальнейшее портирование на MCU


    Продолжается работа над портированием Qt на железо уровня микроконтроллеров. Помимо RTEMS были опробованы FreeRTOS (которая стала выглядеть чуть получше после того как Amazon добавил туда некоторую поддержку POSIX) и uClinux, и пока вывод такой, что мы всё-таки рекомендуем именно RTEMS.


    Говоря о конкретных устройствах, помимо STM32F4/F7 удалось достичь хороших результатов на NXP i.MX RT1050.


    Отказ от Qbs


    Топ 10 предательств в аниме! Вероломно, без объявления войны, в официальном блоге было заявлено об отказе от Qbs.


    Вкратце: разработка Qbs прекращается, хотя и будет выпущен ещё один релиз, поддержка закончится в конце 2019 года, qmake пока останется, но в перспективе (Qt 6) будет осуществлён переход на CMake как основную систему сборки.


    Пост собрал две сотни комментариев (рекорд для нашего блога), и собрал бы больше, но комментарии к постам автоматически закрываются через две недели после публикации. Вот тут ещё есть комментарии на русском.


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


    Изменения в коммерческом лицензировании


    Коммерческое лицензионное соглашение обновилось до версии 4.1. Добавился аппендикс с перечислением лицензируемого/распространяемого ПО.


    Значительно улучшились условия лицензии для стартапов: во-первых, она теперь не со скидкой, а вообще бесплатная, а во-вторых, теперь доступны компоненты и из Device Creation тоже (готовые образы на основе Yocto Linux, тулчейны для кросс-компиляции и т.д.), однако для распространения продуктов-устройств рантаймы покупать всё равно потребуется (логика такая, что если есть деньги на железо, то должны найтись и на рантаймы).


    Лицензия для стартапов выдаётся на год и потом может быть продлена ещё на год. Юридически это полноценная коммерческая лицензия без необходимости выполнять требования GPL/LGPL. После первого года (или двух) она превращается в обычную лицензию за полную стоимость.


    У стартапных лицензий действуют следующие ограничения:


    • годовой доход компании должен быть меньше 100 000 долларов, иначе вы не квалифицируетесь как стартап;
    • получить лицензии можно максимум на 3 разработчиков;
    • техническая поддержка сильно урезана: 5 тикетов в месяц и низкий приоритет в очереди.

    Кстати, не исключено, что вашу заявку на стартапную лицензию будет рассматривать как раз девушка с обложки статьи.


    Другие новости


    В этом году Qt World Summit прошёл два раза: Бостоне и потом в Берлине. Записей выступлений пока нет, есть только короткий видео-обзор берлинского и пост от KDAB.


    Грядёт обновление иконок приложений:


    Новые иконки Qt


    Как вам? Мне тоже. А главное, откуда опять эта нужда в редизайне, не так давно был уже один, и довольно неплохой.


    Компания Forrester провела исследование, в котором изучила влияние Qt на бизнес, всякие там ROI показатели и прочее. Вроде как это должно помочь компаниям оценить пользу от Qt и принять решение о приобретении коммерческой лицензии. Есть даже онлайн-калькулятор для подсчёта сэкономленных попугаев.


    На этом с новостями пока всё, следующий выпуск будет где-нибудь в мае или как наберётся достаточно материала.

    Поделиться публикацией

    Похожие публикации

    Комментарии 59

      0
      В версии 4.8 также должен был быть добавлен модуль телеметрии, но в этот релиз он не попал, так что ожидайте в 4.9.
      Да немного не успели мы к 4.8 :) Потом планируется добавить в Qt Design Studio и, возможно, в 3D Studio.
        +5
        Но в размещении микроконтроллерной статьи НЛО автору отказало

        Если работа по переводу уже проделана, может есть возможность выложить материал на другой площадке (https://telegra.ph/ или что для этого случая будет удобным), а тут в комментариях просто оставить ссылку?
        Думаю, что не только я буду за это благодарен ;)

          0

          Я автору предлагал ещё тогда опубликовать в своём блоге, но что-то не пошло. Да, telegra.ph это хорошая идея, спрошу его.

            +1

            … Спросил, он сказал что будет в telegra.ph, но пока не сделал. Буду его пинговать периодически.

          +1
          Можете больше рассказать о Qt Remote Objects, как они позиционируются вообще? Я посмотрел документацию, примеры, но так и не понял, какое прикладное решение можно с ними нагородить.
          Для обеспечения «банального» IPC куда лучше QtDbus сейчас справляется (он кросплатформенный и так же может работать и по сети).
          Примеры какие-то уж больно синтетические в документации.
            +1

            Ну D-Bus это только Linux, потому на Mac OS и Windows он не работает, а вот Remote Objects — это уже действительно кросс-платформенный модуль. Отличие от других механизмов IPC в том, что он "заточен" под Qt — оригинальный объект и реплика оба являются являются QObject, то есть вы работаете не с чем-то там, а со знакомыми сигналами и слотами.

              0
              «Ну D-Bus это только Linux, потому на Mac OS и Windows он не работает»
              чегоооооо
              О_О
              А я его использовал в промышленной системе на Windows, причем таки в его обертке QtDbus как раз, а оказывается он там не работает…
              (картинка со столом и водкой)
              (а, ну я вроде сам libdbus собирал, не помню, шел ли модуль в стандартном инсталляторе, правда, но факт -это все заводится вполне).

              Вы ничего не перепутали?
              Да, под win сейчас там отключена работа через pipe-ы (там вроде туду было в коде), но через сетевые сокеты все норм работает, и судя по замерам производетельности, это не такая уж большая потеря (большой объем данный по dbus все равно не гоняется)

              «то есть вы работаете не с чем-то там, а со знакомыми сигналами и слотами.»
              вот именно dbus в qt — работаешь с сигналами и слотами. Совершенно естественным кутешным образом. Что не так?
                0

                Из коробки D-Bus только в Linux, на Windows его ещё надо приделать, чтобы пользоваться. Если вот сейчас запустить на любом десктопном Windows пример с машинкой, то приложение контроллера/пульта скажет, что нет подключения к шине, потому что самой шины нет в системе. Но спасибо за информацию, что он таки может там работать, я до этого только знал из вики, что теоретически порт под Windows существует.


                Да, тоже сигналы-слоты, но если говорить о "банальном" IPC как о работающем одинаково на всех платформах, то в этом плане Remote Objects предпочтительнее, потому что им не требуется наличие какой-то системной шины как в случае с D-Bus. Ну и я бы не назвал Qt D-Bus банальным IPC, там не сразу всё так просто работает, надо сначала сгенерировать специальный XML для регистрации методов (впрочем, с Remote Objects почти такая же история).


                Мне самому пока ни разу не пригождался ни тот, ни другой (может просто задач таких не было), потому синтетические примеры из документации реальными дополнить не могу, к сожалению. Ну хотя вот было демо с комбинацией WebGL стриминга и Remote Objects с целью реализации мирроринга (зеркалирования?) GUI между устройствами по сети — можно его рассмотреть в качестве более-менее примера из реальной жизни.

                  0
                  Ну хорошо, по крайней мере из вашего коммента я понял, что сфера применения у них примерно одна и та же, спасибо.
                  Генерация XML протокола — ну да, пожалуй, этого отличия достаточно.
            +2
            Переходят значит на CMake… С софтом часто так — чем уродливей, тем успешней, а все говорят, что красота спасет мир, врут наверное…
              +2
              В плане лицензирования инструмент вроде как заявлен в Open Source (GPLv3), но в то же время вроде как для распространения результатов работы требуется коммерческая лицензия
              А так вообще можно? Это не противоречит GPL?
                0

                Отличный вопрос, я его сам задавал менеджерам продукта, когда стало известно о модели лицензирования, но как я понял они сами ещё не до конца определились, потому что однозначно мне так и не ответили.


                Если бы Qt Design Studio была исключительно коммерческим инструментом (как например Qt Configuration Tool), то и вопросов бы не было.


                Но ведь они же захотели как бы и в Open Source, но одновременно с этим и ограничить использование без коммерческой лицензии. В итоге получилось как в анекдоте про "крестик или трусы": вроде и GPL, а распространять без лицензии нельзя.


                Справедливости ради сейчас план такой, что в скором будущем появится урезанная но полностью свободная версия инструмента, и тогда эта лицензионная суперпозиция исчезнет. Ну а пока вот так.

                +2
                С одной стороны жаль, что qbs закрывают, он мог бы стать более изящной заменой для cmake, но с другой стороны, я давно уже ожидал отказ от qbs и qmake. Это было закономерно.

                Никогда не понимал, зачем эти велосипеды. Проблема в том, что разработчики qbs и qmake никогда не претендовали на универсальность и конкуренцию с cmake, всегда позиционировали qbs и qmake как инструмент нацеленный на Qt инфраструктуру. В такой ситуации, они были обречены на провал рано или поздно т.к. более универсальный инструмент лучше в данной ситуации. Куча популярных C++ библиотек поддерживает интеграцию в cmake-проекты, но я не знаю ни одной популярной (не header-only), которую легко было бы интегрировать в qmake/qbs проект, что бы можно было обойтись без cmake. В результате от cmake отказаться все равно никакой возможности нет.
                  +1
                  За полгода вышло две версии Qt Creator: 4.7 и 4.8.

                  Частые обновление QtCreator — боль для плагинописателей. С каждым обновлением API немного, но меняется, а значит старые плагины перестают подходить к новым версиям и разработчикам сторонних плагинов приходится вносить в них изменения под каждую свежую версию.
                    0
                    Не обновление как таковое, а отсутствие стабильного API. Это как в Linux kernel. По сути, мотивация пропихнуть свой плагин в апстрим примерно такая же — чтобы снять головную боль при изменении API.

                    Более того, не знаю как у вас, я сталкивался с тем что в минорном апдейте все отваливалось даже.
                    0
                    Когда уже поправят вот этот баг? bugreports.qt.io/browse/QTBUG-55654
                    Или
                    поддержка High-DPI для Qt Widgets на Windows (до этого было только в Mac OS и Linux);

                    это как раз про это?
                      0
                      Похоже, что нет… Таки как был там qRound так и остался.
                        +1

                        Написал менеджеру продукта, ответственному за Qt Widgets и вообще десктопы. Надеюсь, он обсудит с командой и что-нибудь сдвинется с места (или таки продолжат работу, или закроют окончательно).

                          0
                          Если будут новости, напишите пожалуйста.
                        0
                        А нормальную сборку для Windows 64-bit так и не завезли? Без зависимостей от Visual Studio? И кстати, в чем тут проблема?
                          0

                          Ну там прям уж не зависимость от Visual Studio, а требование наличия MSVC. А если вы имеете в виду MinGW, то завезли:


                          MinGWx64

                            +2
                            Завезли же. Сейчас сборка Qt для Windows есть с MinGW 7, 64-bit only
                              +1
                              Проблема была и наверное есть в Mingw64. Который как бы странный, что ли неофициальный он, не знаю как сейчас, я его как-то не с первого раза подобрал и уже много лет сам собираю Qt на нем для своих проектов.
                              VS было лень использовать по причине большого легаси кода, который всегда работал на GCC и есть проблемы переносимости на VS, такие как работа с указателями на функции члены класса, инициализация массивов на стеке и прочие нестыковки с мелкомягкими.
                                0
                                Mingw64 это форк Mingw, в нем нет ничего неофициального. Запиливание полноценной работы с 64-битной виндой изначально было одним из приоритетов проекта.

                                Меня немного удивило то что 32-битных сборок mingw теперь нет)
                                  0

                                  Не только вас. В рассылке это как раз обсуждают. Там кстати привели отличный аргумент, что для никому не нужного UWP поставляется аж 6 комплектов бинарников, а для MinGW не могли x32 оставить. Ну и вроде команда внезапно задумалась, как так получилось.

                                    0
                                    Так поддержки QtWebEngine все равно же под mingw нет и не будет. Ожидается ли поддержка clang?
                                    Since October 2017, clang is the default [Chromium] compiler on Windows.

                                    И даже сборка с lld вроде работает.
                                      0

                                      Сколько ни спрашивали об этом команду WebEngine, но пока сборка под Windows только с MSVC. Можете присоединиться к тикету.

                                        0
                                        Но даже если WebEngine переведут на clang/lld, clang не входит в список поддерживаемых Qt платформ под win, в отличии от mingw.
                                          +2

                                          Пока не входит, но работа идёт. Оба тикета, разумеется, связаны.

                              +2
                              А не планируется никак переписывать внутренности Qt'а с поддержкой C++11/14/17/2a и ближе интегрироваться с stl? Или может быть как-то влиять на этот самый stl и стандарт?

                              А то QString очень приятно использовать, но некоторые вещи хочется взять из boost'а, некоторые из std (тот же string_view, например) и получается, что в одном проекте в разных неймспейсах 10 видов одних и тех же контейнеров.
                                +1
                                Умоляю по-тише, а то они и от QtCore откажутся в пользу STL + BOOST…
                                  +1
                                  Давно пора. Как от qmake/qbs отказались, так и от QtCore придется.
                                    +2
                                    Чур меня. В QtCore слишком много вкусного чего нет в stl.
                                      0
                                      Если и так, то лучше бы они выделили это в отдельную небольшую библиотеку, которую можно было бы использовать отдельно от фреймворка и под более permissive лицензией чем LGPL. Что-то вроде Eigen, rapid_json, Catch2 и т.п.

                                      Но вообще, я не знаю, что такого вкусного* есть в Qt, что лучше имеющихся универсальных аналогов. Даже реализация signal/slot механизма из Qt выглядит на сегодня не самой удачной.
                                      * кроме вещей связанных с GUI напрямую, естественно.
                                        0

                                        Но чем LGPL недостаточно permissive?

                                          0
                                          Тем, что накладывает ограничения на static linkage, а также bare metal, например. MPL, к примеру, не страдает от таких недостатков.
                                          This allows, for example, programs using MPL-licensed code to be statically linked to and distributed as part of a larger proprietary piece of software, which would not generally be possible under the terms of stronger copyleft licenses.
                                              0
                                              Это распространенное заблуждение, про то что GPL/LGPL речь только о dll-ках.
                                              Ты можешь Qt поставлять и в виде dll-ки, но если в приложении будешь проверять его чексумму, например, LGPL будет нарушен, т.к. пользователь не сможет сам заменить библиотеку.
                                                0
                                                Что не подходит для header-only библиотек, что было бы в данном случае вполне уместно. Кроме того, необходимость предоставлять объектные файлы — не очень.
                                                  0
                                                  «Кроме того, необходимость предоставлять объектные файлы — не очень.»
                                                  а что конкретно не очень?
                                                  в них содержится столько же информации, сколько и в dylib/so, ну если не оставлять дебажные символы, конечно. Я не прав?
                                                  Неудобно для пользователя — возможно, но мы же о соблюдении лицензии и ее свобод говорим.
                                                    0

                                                    Не очень то, что разработчику неудобно. Lgpl не может быть header only. Защита свобода пользователя, с моей точки зрения, все равно достижима только если вся программа свободна, a LGPL этого не гарантирует. Свобода части программы ничем не лучше полностью несвободной программы, мне кажется. Зато LGPL удобству разработчика препятствует.

                                                      0
                                                      Да, с этим полностью согласен.

                                                      Видели такое? Я не спец, но что-то такое) сам eigen не использовал.
                                                      eigen.tuxfamily.org/index.php?title=Licensing_FAQ&oldid=1117#What_is_the_LGPL.3F
                                                        0
                                                        Я не знал про эти особенности LGPL, но сейчас авторы Eigen поменяли лицензию на MPL2:
                                                        This page used to have a long FAQ that we thought was useful when Eigen was LGPL-licensed.
                                                        Now that Eigen is MPL2-licensed, there is no need anymore for that.
                                            0
                                            Не буду расписывать всё что использую — остановлюсь на одном.
                                            QByteArray/QDataStream — для работы с бинарными данными великолепные инструменты. Заменить конечно можно но функционала не будет хватать. Я писал два варианта небольшой библиотеки с stl и c qt — так вот без QByteArray как без рук.
                                              0
                                              Ну библиотек для сериализации под C++ хватает. Если нравятся потоки — Boost.Serialization, а так — protobuf, cereal, etc. И они более портируемы и софт с ними легче поддерживать. Лицензии более разрешительные.
                                                0
                                                Вы не поняли. Сериализация это то же хорошо и QDataStream неплохо решает. Но я про работу с сырыми бинарными данными. Например у меня задача работы со смарткартами по APDU. Там туда-сюда пересылаются пакеты в бинарном виде которые мне надо формировать и парсить. QByteArray для этого очень удобен. А вот вами перечисленное нет ибо переусложнено.
                                                А по поводу портируемости и поддержки я бы поспорил. Чем вам портируемость Qt не нравиться. А поддержка ИМХО удобней чистого ООП как в Qt, чем например шаблонного ада boost или С-style protobuf.
                                    0
                                    Странное дело — чем новее версия Qt (и Qt Creator), тем больше в ней багов. В итоге, я для себя решил откатиться к золотой версии 5.8, потому что на ней у меня ничего не отваливается и не рушится на старых проектах.
                                      0
                                      Проекты случайно OpenGL не используют?
                                        0
                                        Нет, не используется. Просто фронтэнды к базам данных или программы для химических вычислений.
                                      0
                                      Еще нигде не упоминается, но в Qt Creator добавили плагин Cppcheck.
                                      Помечен как экспериментальный и по умолчанию отключен.
                                      Можно включить через меню About Plugins…
                                        0
                                        Это он код превращает в желтый ад? Или это еще один из тех кто будет свистеть каждому неявному касту — мол потеря точности и прочим вещам подпадающим под примитивные правила без разбора контекста? Увы без возможности фильтрации сообщений, несмотря на всю ценность статических анализаторов — вынужден был отключить это безобразие, ведь код я все еще пишу для людей и не намерен превращать код в нагромождение static_cast<...>(...) и прочих излишеств в угоду подавления сообщений.
                                          0
                                          Нет, это вы о Cland Code model.
                                          Как я уже сказал, Cppcheck отключен по умолчанию.
                                            0
                                            Ясно, как обновлюсь, надо будет попробовать, может он все же поумнее окажется.
                                            Плохо, что настроек нет для отключения конкретных сообщений, для Cppcheck наверное тоже не стоит ожидать настройки фильтров?
                                              +1
                                              Почитайте cppcheck.sourceforge.net
                                              Там можно добавлять флаги для запуска.
                                              Скрытый текст
                                                0
                                                Для clang code model тоже все отключается. Задайте флаги -Wall, например, исключите там то что вам не нравится и радуйтесь.
                                                C++->Code Model-> Manage…
                                            +1

                                            В релизном посте писали об этом, на OpenNET тоже было.

                                            0
                                            Вот вроде прекрасная и, наверное, единственная платформа в С++, но какая-то не законченная для прикладной разработки.

                                            Начинаешь писать мобильный факультативчик, быстро выясняется, что из коробки для рекламы и аналитики ничего нет (н-р, интеграции с Firebase).

                                            А далее выясняется, что для крашрепортинга тоже ничего нет, хотя, как я понимаю, платформа сейчас нацелена на embed разработку. При этом с каждом релизом появляются и исчезают модули сомнительной полезности.
                                              0

                                              Да, мобильные платформы «из коробки» обделены вниманием, мягко говоря.


                                              Но есть хороший сторонний фреймворк — Felgo (ранее V-Play). Там многое из перечисленного вами присутствует.

                                                0
                                                Вот это удивляет.

                                                Про V-Play знаю, но дело даже не в том, что они денег хотят. Они привносят слишком много своего, включая базовые компоненты, плюс получается сразу слишком много новых интеграций.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое