Comments 59
В версии 4.8 также должен был быть добавлен модуль телеметрии, но в этот релиз он не попал, так что ожидайте в 4.9.Да немного не успели мы к 4.8 :) Потом планируется добавить в Qt Design Studio и, возможно, в 3D Studio.
Но в размещении микроконтроллерной статьи НЛО автору отказало
Если работа по переводу уже проделана, может есть возможность выложить материал на другой площадке (https://telegra.ph/ или что для этого случая будет удобным), а тут в комментариях просто оставить ссылку?
Думаю, что не только я буду за это благодарен ;)
Для обеспечения «банального» IPC куда лучше QtDbus сейчас справляется (он кросплатформенный и так же может работать и по сети).
Примеры какие-то уж больно синтетические в документации.
Ну D-Bus это только Linux, потому на Mac OS и Windows он не работает, а вот Remote Objects — это уже действительно кросс-платформенный модуль. Отличие от других механизмов IPC в том, что он "заточен" под Qt — оригинальный объект и реплика оба являются являются QObject, то есть вы работаете не с чем-то там, а со знакомыми сигналами и слотами.
чегоооооо
О_О
А я его использовал в промышленной системе на Windows, причем таки в его обертке QtDbus как раз, а оказывается он там не работает…
(картинка со столом и водкой)
(а, ну я вроде сам libdbus собирал, не помню, шел ли модуль в стандартном инсталляторе, правда, но факт -это все заводится вполне).
Вы ничего не перепутали?
Да, под win сейчас там отключена работа через pipe-ы (там вроде туду было в коде), но через сетевые сокеты все норм работает, и судя по замерам производетельности, это не такая уж большая потеря (большой объем данный по dbus все равно не гоняется)
«то есть вы работаете не с чем-то там, а со знакомыми сигналами и слотами.»
вот именно dbus в qt — работаешь с сигналами и слотами. Совершенно естественным кутешным образом. Что не так?
Из коробки D-Bus только в Linux, на Windows его ещё надо приделать, чтобы пользоваться. Если вот сейчас запустить на любом десктопном Windows пример с машинкой, то приложение контроллера/пульта скажет, что нет подключения к шине, потому что самой шины нет в системе. Но спасибо за информацию, что он таки может там работать, я до этого только знал из вики, что теоретически порт под Windows существует.
Да, тоже сигналы-слоты, но если говорить о "банальном" IPC как о работающем одинаково на всех платформах, то в этом плане Remote Objects предпочтительнее, потому что им не требуется наличие какой-то системной шины как в случае с D-Bus. Ну и я бы не назвал Qt D-Bus банальным IPC, там не сразу всё так просто работает, надо сначала сгенерировать специальный XML для регистрации методов (впрочем, с Remote Objects почти такая же история).
Мне самому пока ни разу не пригождался ни тот, ни другой (может просто задач таких не было), потому синтетические примеры из документации реальными дополнить не могу, к сожалению. Ну хотя вот было демо с комбинацией WebGL стриминга и Remote Objects с целью реализации мирроринга (зеркалирования?) GUI между устройствами по сети — можно его рассмотреть в качестве более-менее примера из реальной жизни.
В плане лицензирования инструмент вроде как заявлен в Open Source (GPLv3), но в то же время вроде как для распространения результатов работы требуется коммерческая лицензияА так вообще можно? Это не противоречит GPL?
Отличный вопрос, я его сам задавал менеджерам продукта, когда стало известно о модели лицензирования, но как я понял они сами ещё не до конца определились, потому что однозначно мне так и не ответили.
Если бы Qt Design Studio была исключительно коммерческим инструментом (как например Qt Configuration Tool), то и вопросов бы не было.
Но ведь они же захотели как бы и в Open Source, но одновременно с этим и ограничить использование без коммерческой лицензии. В итоге получилось как в анекдоте про "крестик или трусы": вроде и GPL, а распространять без лицензии нельзя.
Справедливости ради сейчас план такой, что в скором будущем появится урезанная но полностью свободная версия инструмента, и тогда эта лицензионная суперпозиция исчезнет. Ну а пока вот так.
Никогда не понимал, зачем эти велосипеды. Проблема в том, что разработчики qbs и qmake никогда не претендовали на универсальность и конкуренцию с cmake, всегда позиционировали qbs и qmake как инструмент нацеленный на Qt инфраструктуру. В такой ситуации, они были обречены на провал рано или поздно т.к. более универсальный инструмент лучше в данной ситуации. Куча популярных C++ библиотек поддерживает интеграцию в cmake-проекты, но я не знаю ни одной популярной (не header-only), которую легко было бы интегрировать в qmake/qbs проект, что бы можно было обойтись без cmake. В результате от cmake отказаться все равно никакой возможности нет.
За полгода вышло две версии Qt Creator: 4.7 и 4.8.
Частые обновление QtCreator — боль для плагинописателей. С каждым обновлением API немного, но меняется, а значит старые плагины перестают подходить к новым версиям и разработчикам сторонних плагинов приходится вносить в них изменения под каждую свежую версию.
Или
поддержка High-DPI для Qt Widgets на Windows (до этого было только в Mac OS и Linux);
это как раз про это?
Написал менеджеру продукта, ответственному за Qt Widgets и вообще десктопы. Надеюсь, он обсудит с командой и что-нибудь сдвинется с места (или таки продолжат работу, или закроют окончательно).
Ну там прям уж не зависимость от Visual Studio, а требование наличия MSVC. А если вы имеете в виду MinGW, то завезли:
VS было лень использовать по причине большого легаси кода, который всегда работал на GCC и есть проблемы переносимости на VS, такие как работа с указателями на функции члены класса, инициализация массивов на стеке и прочие нестыковки с мелкомягкими.
Меня немного удивило то что 32-битных сборок mingw теперь нет)
Не только вас. В рассылке это как раз обсуждают. Там кстати привели отличный аргумент, что для никому не нужного UWP поставляется аж 6 комплектов бинарников, а для MinGW не могли x32 оставить. Ну и вроде команда внезапно задумалась, как так получилось.
Since October 2017, clang is the default [Chromium] compiler on Windows.
И даже сборка с lld вроде работает.
Сколько ни спрашивали об этом команду WebEngine, но пока сборка под Windows только с MSVC. Можете присоединиться к тикету.
Пока не входит, но работа идёт. Оба тикета, разумеется, связаны.
А то QString очень приятно использовать, но некоторые вещи хочется взять из boost'а, некоторые из std (тот же string_view, например) и получается, что в одном проекте в разных неймспейсах 10 видов одних и тех же контейнеров.
Но вообще, я не знаю, что такого вкусного* есть в Qt, что лучше имеющихся универсальных аналогов. Даже реализация signal/slot механизма из Qt выглядит на сегодня не самой удачной.
* кроме вещей связанных с GUI напрямую, естественно.
Но чем LGPL недостаточно permissive?
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.
Ты можешь Qt поставлять и в виде dll-ки, но если в приложении будешь проверять его чексумму, например, LGPL будет нарушен, т.к. пользователь не сможет сам заменить библиотеку.
а что конкретно не очень?
в них содержится столько же информации, сколько и в dylib/so, ну если не оставлять дебажные символы, конечно. Я не прав?
Неудобно для пользователя — возможно, но мы же о соблюдении лицензии и ее свобод говорим.
Не очень то, что разработчику неудобно. Lgpl не может быть header only. Защита свобода пользователя, с моей точки зрения, все равно достижима только если вся программа свободна, a LGPL этого не гарантирует. Свобода части программы ничем не лучше полностью несвободной программы, мне кажется. Зато LGPL удобству разработчика препятствует.
Видели такое? Я не спец, но что-то такое) сам eigen не использовал.
eigen.tuxfamily.org/index.php?title=Licensing_FAQ&oldid=1117#What_is_the_LGPL.3F
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.
QByteArray/QDataStream — для работы с бинарными данными великолепные инструменты. Заменить конечно можно но функционала не будет хватать. Я писал два варианта небольшой библиотеки с stl и c qt — так вот без QByteArray как без рук.
А по поводу портируемости и поддержки я бы поспорил. Чем вам портируемость Qt не нравиться. А поддержка ИМХО удобней чистого ООП как в Qt, чем например шаблонного ада boost или С-style protobuf.
Помечен как экспериментальный и по умолчанию отключен.
Можно включить через меню About Plugins…
Как я уже сказал, Cppcheck отключен по умолчанию.
Плохо, что настроек нет для отключения конкретных сообщений, для Cppcheck наверное тоже не стоит ожидать настройки фильтров?
В релизном посте писали об этом, на OpenNET тоже было.
Начинаешь писать мобильный факультативчик, быстро выясняется, что из коробки для рекламы и аналитики ничего нет (н-р, интеграции с Firebase).
А далее выясняется, что для крашрепортинга тоже ничего нет, хотя, как я понимаю, платформа сейчас нацелена на embed разработку. При этом с каждом релизом появляются и исчезают модули сомнительной полезности.
Да, мобильные платформы «из коробки» обделены вниманием, мягко говоря.
Но есть хороший сторонний фреймворк — Felgo (ранее V-Play). Там многое из перечисленного вами присутствует.
Новости Qt, май 2018 — декабрь 2018