Комментарии 9
Как по мне так единственное что стоит использовать - это наследование от QQuickPaintedItem и QQuickItem. В таком случае можно обойтись обычной статической библиотекой и непонятно зачем городить огород с плагином(модулем).
Новые виджеты хочешь - не хочешь, а создаешь всегда, в этом концепция QML. Любой qml файл это уже новый виджет. Я бы назвал статью - разные способы рисования в QML.
Если нужно что-то сложное рисовать, то вероятно вам захочется делать это быстро или очень быстро, и тут добро пожаловать в С++.
C++ не гарантия скорости, ведь код компонента - это рецепт для движка рендера, уже который будет делать самую тяжёлую работу. В Qt Quick полезнее правильно подготовить сцену для отрисовки, чтобы как можно меньше было клиппинга и чтобы использовать батчинг на полную катушку. Поэтому если существует возможность сделать компонент из стандартных, проще не заморачиваться низкоуровневым кодом, толку от этого практически не будет.
C++ не гарантия скорости
У автора в статье график - самое быстрое это манипулировать QSGNode. Так что не гарантия, кривые руки могут испортить все, но это способ получить самую быструю отрисовку.
если существует возможность
Ну примерно о этом и сказал, если нужен виджет который показывает примерно одинаковые списки, просто делайте свою qml'ку на основе listview и не парьтесь. Свой виджет нужен когда надо рисовать что-то очень замороченное, например флеймграф колстека(это то для чего мне приходилось делать) или карту игры. В любой программе на QML которая сложнее лабораторки студента так или иначе появляется своя библиотека виджетов, обычно это обвязка над стандартными каких-то специфичных для программы функций.
Не знаю как в шестом, но в 5-ом был один очень неприятный для меня момент, который если честно непонятно зачем был сделан. Если вы делаете свой виджет на основе QQuickItem то вам дорога делать кастомные QSGNode или использовать стандартные и вот в стандартных нет нода для отрисовки текста(!!!), он в приватном АПИ qt. У меня от этого факта реально конкретно подгорело в свое время. Типа в смысле? Выводить текст это прям то что нужно буквально сразу как делаешь кастомный виджет, почти всегда. Какого хрена? До сих пор не могу понять зачем они его сделали внутри приватного апи, откуда его не так просто достать, и делать этого явно не стоит.
Поэтому если вы планируете рисовать текст вам дорога в QQuickPaintedItem или делайте свою отрисовку текста, что вообще не тривиальная задача. Как вариант рендерить в текстуру и рисовать текстурки, но то же такое. А если хочется текст правильно рисовать... короче обычный программист это не сделает с первого раза, когда строится текстурный атлас шрифта, и потом начинается долго и упорно побеждать хинтинг шрифтов и uft8.
В целом можно обойтись и без модуля для QtCreator, если делать компоненты только на QML. В этом случае это будет вполне сносоно работать и в режиме Design. Но если делать на C++, то придётся собрать всё в модуль. Для единообразия всё было оформлено в одну библиотеку.
Первоначальное название почти угадали - "7 способов нарисовать кург в QML".
Не понимаю что вы имеете ввиду? Вы берете и наследуетесь от QQuickItem, это будет обычный С++ класс(с поправкой на мок, QObject и прочее), но в итоге это соберется в обычный объектный файл. Останется только регистрацию в самом приложение сделать(qmlRegisterType).
Да, верно, это будет работать, если скомпилировать и запустить приложение. При этом сохраняется возможность встроить такой элемент в QML файл этого же приложения. Но я хотел показать способ использовать кастомный компонент именно в дизайнере. Тут, чтобы графический редатор смог подцепить наш элемент нужно собрать библиотеку и разместить сам бинарник библиотеки, все ресурсы (тиипа картинок) и метанформацию (файл .qmltypes) в директориях установленного Qt, используя который планируется сборка итогового приложения. Вобщем контекст такого подхода именно в использовании компонента в графическом редакторе.
Это безусловно полезно и скорее всего мне пригодиться вот прям скоро. Обычно нет необходимости так делать, в своих рабочих проектах такого избегал, потому что зачем добавлять сложность в проект, если можно без этого, лучший код которого нет, но вот прям сейчас в рамках домашнего проекта задумал сделать библиотеку которая выключает стандартные рамки окна(не знаю как правильно называется) и использует свой декоратор, свои кнопки закрытия, сворачивание и прочее. Это достаточно изолированная часть и надоело таскать из проекта в проект код, проще действительно сделать либу(плагин) и вот это все, что вы описали и положить в отдельный репозиторий. Последний раз плагины делал на Qt 3.7 ))) лет 20 назад, с тех пор конечно много поменялось.
Мне доводилось видеть проект где вместо обычных статических либ было разбиение проекта именно на qt плагины, причем обоснования не было, просто вот так захотелось кому-то в команде на ранних стадиях разработки, сложность сразу выросла, как по сборке, так и по разработке. Не драматично, но постоянно что-то из-за этого мешалось, конкретных деталей уже не вспомню, давно было, помню общие ощущения от работы.
Qt дает много фичей, некоторые из них надо применять очень редко и очень в особых случаях, они могут быть хороши для самой библиотеки, но для приложения вредить, вот в чем моя мысль.
Отличная статья, единственно, подход к бенчмаркингу удивил. Не лучше ли воспользоваться пускай и стандартным таймером в том же треде, но точнее вычислить промежуток времени через QElapsedTimer?
Способы создания пользовательских компонентов в QML