Полезные библиотеки для QML

[TOC]

Много всего полезного https://github.com/mikalv/awesome-qt-qml

Для моделей

  1. https://github.com/benlau/qsyncable QSyncable - Synchronize data between models
  2. https://github.com/diro/qml_underscorejs Для работы с моделями на JS

Точно поллезные qml “приблуды”

  1. FontAwesome для упрощения верстки , значки https://github.com/benlau/fontawesome.pri
    • ими можно заменить все qrc:/icons/some.svg чтобы отвязаться от с++ svg_item.h
  2. Диалог открытия файлов https://github.com/paulondc/quicknative

Компоненты // библиотеки компонентов

  1. наш Industrial controls …. другая ссылка

    • не хорошо:
      • есть серьезная с++ зависимость, которая требует линковки с библиотекой чтобы “особым образом” проинициализировать.
      • компоненты так сделаны, что их использование повлечет привязку логики приложения к этой библиотеке и потом не перейти на другую.
    • хорошо:
      • есть темы и стили
      • это библиотека с компонентами, которых по идее должно быть достаточно чтобы что-то делать.

  2. industrial_indicators … линк1 линк2

    • хорошо: ситуация лучше, чем у industrial_controls. это чистый qml + js.
    • не очень прекрасно: темы сделаны хотя и схожим образом, но настройки значений темы не совпадают, форма и состав полей темы не совпадают. (но и не обязан…)

  3. https://github.com/brexis/qml-bootstrap типа Бутстрап компоненты , БЕЗ с++

    • плохо:
      • к сожалению сделан не как библиотека, а как проект в котором трудно понять, что библиотека, а что сделано стандартными средствами
      • из него библиотеку надо еще сделать… структура плоха.
    • хорошо: чистый qml + js, жить можно, но простовато

  4. https://github.com/lirios/fluid много компонентов, библиотека, есть с++

    1. qml компоненты описаны тут https://docs.liri.io/sdk/fluid/develop/ описание плохое, без картинок
    2. c++ компоненты:
      1. DatePicker
      2. DateSelector
      3. Color
      4. Utils
      5. WindowDecoration
      6. IconCategoryModel
      7. IconNameModel

  5. https://github.com/benlau/quickios для iOS несколько базовых компонентов чтобы начать простое приложение

    • плохо: компоненты на столько базовые, что считай их нет.

  6. https://github.com/benlau/sparkqml Таблицы с данными

  7. https://github.com/chili-epfl/qml-cache аналог LocalStorage для QML

  8. Docking system

    1. https://github.com/unseon/QQuickDock
    2. https://github.com/mfreiholz/Qt-Advanced-Docking-System

  9. https://github.com/Skycoder42/QtMvvm подборка с целым видением как делать и проект и виджеты

  10. https://github.com/Skycoder42/QtRestClient REST запросы где JSON ответы сами превращаются в QObject свойства. Полезная штука, даже как паттерн

  11. https://github.com/Waqar144/QSourceHighlite быстрая подсветка кода многих языков программирования

Комментарии по компонентам

Это все не компоненты в нормальном смысле., даже industrial_controls.

Там нет никакой изоляции, никакой типизации… с редюсерами все плохо, с обновлением по сигналам не очень хорошо.

Изворотливый человек сможет их так использоовать, как не предполагалось разработчиками и это создаст новые проблемы. но это проблемы скорее самого qml.

Замечание по языку QML: (субъективно, но верно)

Когда определено содержимое блока/компонента внутри его qml файла оно должно содержать явное описание параметров, которые приходят снаружи.

!!! Возможность, используя блок/компонент снаружи ПЕРЕОПРЕДЕЛИТЬ и даже ДОПОЛНИТЬ блок/компонент вызывает фрустрацию.

  1. переопредлять внутренности блока/компонента нельзя! Если хочется: то нужно иметь параметры, которые самому компоненту говорят как он сам должен это делать. перегруппируйте код: Выделите общие блоки в отдельные компоненты, используйте общие части в своем компонентие и тот, от которого пошла идея, переписав его по новому, используя общие части.
  2. удалять (заменяя пустым) часть блока нельзя. Если хочется - нужно иметь параметры, читая которые блок/компнент сам не будет их рисовать
  3. Дополнять блок/компонент нельзя. Если хочется, то ты должен сделать новый блок/компонент, который и будет являться композитом, который ты хотел. Должно произойти “порождение компонента”. Дополнение компонента, добавлением ВНУТРЬ ему вякого извне - плохой стиль. добавляется не толко ВИД, но и даже логика и состояния… Это ужасно!
    1. в то же время это нормальная практика для лайаутов, или базовых не видимых блоков (сложное позиционирование)
  4. обращение по id внутри модуля или в другой qml файл. Это скорее баг чем фича. неявная связь.
  5. property alias имеет синтаксис, который использует id (= способствует засилю id в qml ) поэтому дополнтиельно запутывает структуру и запутывает автоматический анализ qml кода. Получается, это плохая практика, пусть даже она “нравится программистам” - не все что нравится программистам есть хорошо

Как определить что из нежелательного происходит? Пример плохих признаков:

  1. новые свойства не на самом верхнем уровне qml вложенности. говорят о создании состояния не на уровне компонента а ниже - возможно часть кода стоит вынести в отдельный компонент, декомпозировать
  2. Если компонент определен в отдельном файле а мы, используя его, внутри вкладываем в него не один а на больше уровней других компонентов, то лучше перегруппировать все так, чтобы все эти элементы были сами вложены в лайаут или невидимые блоки (используемые для позиционирования), чем друг в друга. Другими словами: определенные нами компоненты должны быть листьями дерева, а не узлами (лайауты - исключения).
  3. обращения по id “куда не следует” трудно засечь.
Мысль / идея автоматический анализ QML

чтобы обнаруживать это автоматом надо парсер QML.

Есть уже такой : https://github.com/qmlweb/qmlweb-parser .

Примеры src & dest here: https://github.com/qmlweb/qmlweb-parser/tree/master/tests/qml .

Используя даже jq и bash можно писать тесты, выявляющие странные неудачные места в qml

Мысль / идея палитра всех компонентов

Чтобы сделать браузер компонентов есть на плохое шаблонное решение https://github.com/benlau/sparkqml это браузер компонентов у которых выделены отдельно еще и состояния. Хорошо для тех кто делает свои компоненты. этакий “демо”

“Философские” вопросы

Как определить границу между бекендом и фронтендом ?

Идеологически:

  • все что за API - бекенд
  • перед API - фронтенд.

Апи у нас предоставляют “сервисы”… даже внутри standalone desktop приложения.

Глобальность состояния (стоит ли все помещать в с++?)

два способа мыслить:

  1. Комполненты. все есть новый компонент, мы их перестраиваем, а не управляем ими. тогда надо умело создавать “локальные” состояния и гибко их двигать и перегруппировывать при изменении ситуации.
  2. Виджеты. все есть композит готовых типовых элементов, которыми надо управлять. тогда логику во фронтенде писать бужет не особо удобно - возникнет желание поместить все состоняие на “самый верх” (или даже в с++).

2-й путь - тупиковый. и так мы не сможем быстро и отдельно разрабатывать…

  • для тестирования придется делать отдельные состония в с++ (не быстро потому что компиляция занимает время) или в js (не быстро потому что это аналог с++ состояния и будет плохо стыковаться друг с другом и все будет на костылях)
  • в с++ будет все “прокинуто” и там , изоляцию трудно контролировать - возникнет система сайд-эффектов.
  • кривая скорости разработки идет вниз - практика так показывает, чего только непридумывали с этим. Проект начинает пробуксовывать, “вязнет” в своем же коде.

1-й путь лучше.

  • У компонентов выше степень изоляции логики, состояние меньше, проще, управляемость выше.
  • состояние будет на js в и для работы и для тестов. (важне не где оно будет, а какое… не могу получше слова подбрать. не то сказал сейчас.)
  • состояние будет родным для qml и будет легко разрабатывать ГИП без с++ слоя
  • можно будет а) генерировать код для синхронизации состояния 2) использовать разные шины 3) видеть состояние шин и данных - удобнее наладка.
  • меньше с++ копиляций для работы с фронтендом (хотя этого все равно не избежать)

Анимации

Общее описание видов и параметров анимаций https://doc.qt.io/qt-5/qml-qtquick-propertyanimation.html

При изменении высоты \ плавное изменение свойства

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Rectangle {
    anchors.left: parent.left
    anchors.right: parent.right
    anchors.top: parent.top
    anchors.margins: 16
    color: "#ccc"
    height: Math.min(listView.contentHeight + 16, cardList.height )

    Behavior on height {
        NumberAnimation {
            property: "height"
            duration: 200
            easing.type: Easing.OutQuad
        }
    }

Реакция на сигнал (или метод?)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
ListView {
    id: board

    orientation: ListView.Horizontal
    model: CardListStore

    add: Transition {
        NumberAnimation {
            properties: "opacity";
            from: 0;
            to: 1;
            duration:200;
            easing.type: Easing.OutQuad;
        }
    }

Еще пример со списком: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
ListView {
    id: listView
    clip: true

    anchors.fill: parent

    add: Transition {

        NumberAnimation {
            property: "opacity";
            from: 0;
            to: 1;
            duration: 200
            easing.type: Easing.OutQuad;
        }
    }

    addDisplaced: Transition {
        NumberAnimation {
            properties: "x,y";
            duration: 200
            easing.type: Easing.OutQuad;
        }
    }

    remove: Transition {
        NumberAnimation {
            property: "opacity";
            from: 1;
            to: 0;
            duration: 200
            easing.type: Easing.OutQuad;
        }
    }

    removeDisplaced: Transition {
        NumberAnimation {
            properties: "x,y";
            duration: 200
            easing.type: Easing.OutQuad;
        }
    }

    move: Transition {
        NumberAnimation {
            properties: "x,y";
            duration: 200
            easing.type: Easing.OutQuad;
        }
    }

    moveDisplaced: Transition {
        NumberAnimation {
            properties: "x,y";
            duration: 200
            easing.type: Easing.OutQuad;
        }
    }

обсуждение этих анимаций ссылка: https://stackoverflow.com/questions/62109636/qml-remove-animation-of-listview-item-with-a-qsqltablemodel

Последовательность анимаций

Вызято отсюда https://stackoverflow.com/a/62149708/2355077

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
remove: Transition {
    SequentialAnimation {
        NumberAnimation {
            property: "opacity"
            from: 1.0
            to: 0
            duration: 400
        }
        ScriptAction {
            script: {
                qsoModel.select()
            }
        }
    }
}

Бесконечное повторение нескольких анимаций

1
2
3
4
5
6
7
8
9
10
Rectangle {
    width: 100; height: 100
    color: "red"

    SequentialAnimation on x {
        loops: Animation.Infinite
        PropertyAnimation { to: 50 }
        PropertyAnimation { to: 0 }
    }
}

QSyncable

Как вариант для с++ моделей qml приложения. Уменьшает рутину

Design Principle - Separation of “updates” and “queries

QSyncable предназначен для решения фундаментальной проблемы приложений C++ и QML: обмен данными между C++ и QML

Модель списка QObject* определенно плохая идея. Ужасно управлять их жизненным циклом и владением (сфера применения QML/C++). Нужно знать о сборке мусора в вашей модели списка QObject*, даже если она написана на C++.

Лучше использовать модель variant list, но она неудобна для C++. И сложно справиться с моделью вложенного списка.

Все будет проще, если разделить «обновления» и «запросы» на разные компоненты. Прежде всего, вам даже не нужно рассматривать подход модели списка QObject*. Нет никаких преимуществ использования модели списка QObject*, если вы используете другой компонент для обновления.

Нет необходимости использовать модель variant list в качестве центрального источника данных. Можно использовать любую структуру данных, которая вам нравится. Можно оставьте модель variant list только для отображения.

QSyncable делает шаг вперед. Он упрощает процесс обновления модель variant list из источника данных, объединяя операции вставки, удаления, перемещения и изменения в один процесс — исправление, сохраняя при этом правильность ответа пользовательского интерфейса. Он решает не только проблему совместного использования данных C++ и QML, но и решение модели вложенных списков в QML.

Моя, пока просто, мысль:

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

Общая идея

  1. на с++ стороне пишется любая модель которая вам нравится. там может происходить, что угодно. примеры: board.h card.h list.h
  2. на верхнем уровне с++ определяются действия для мутации модели (Actions) , ссылка на строку и ниже несколько методов эти методы и вызываются из qml - они меняют с++ модель так, как определено в методах. при этом это никак не отражается на qml интерфейсе
  3. у с++ модели определен метод sync который и предназначен для изменения/применения модели в qml. не надо звать его автоматически везхде - его надо звать в конце Actions действий если даннные для отображения актуальны (например когда они пришли по сети) пример как это делается
  4. данный метод описа ниже и вот что он делает:

пример реализации метода sync

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// It is the only way to update QML model, you don't need
// to handle move, insert, remove operations explicitly.
QVariantMap map = m_board.toMap();

QVariantList lists = map["lists"].toList();

QSDiffRunner runner;

// It is important to set an unique key field on input data.
// Otherwise, it won't be able to generate insertion, removal and move patch.
runner.setKeyField("uuid");

QList<QSPatch> patches = runner.compare(cardListStore->storage(),
                                        lists);

runner.patch(cardListStore, patches);
  • вся наша с++ модель преобразуется в QVariantList (там должны быть проставленый уникальные метки/поля объектам для быстрого сравнения, в данном случае это поле uuid)
  • считаем ПАТЧИ между там, что должно быть в qml и что сейчас отображается
  • применяем патчи к отображаемой модели типа QSListModel* cardListStore; чтобы изменить ее оптимальным образом. Алгортмы в этом процессе действительно быстры (это аналог виртуального DOM в недрах jsx reactjs) Пруф№1 Пруф№2 (но это только в палнах, пока не реализовано)

Итого, у нас на с++ стороне определено два поля. Одно - модели с++ второе - отображаемая в QML модель 

1
2
3
private:
    QQmlApplicationEngine m_engine;
    QSListModel* cardListStore;

При этом наши модели имеют примерно такую “сериализацию”:

1
2
3
4
5
6
7
8
9
10
11
12
13
QVariantMap Board::toMap() const
{
    QVariantMap res;

    QVariantList lists;
    for (int i = 0 ; i < d->lists.size() ; i++) {
        lists << d->lists[i].toMap();
    }

    res["lists"] = lists;

    return res;
}

Пример как работают с Actions - хорошая практика

Регистрация всячины и запуск приложения:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
QString persistFilePath = persistDir + "/persist.json";
m_board.load(persistFilePath);

m_engine.rootContext()->setContextProperty("PersistFilePath", persistFilePath);

m_engine.rootContext()->setContextProperty("App", this);

m_engine.rootContext()->setContextProperty("CardListStore", cardListStore);

m_engine.load(QUrl(QStringLiteral("qrc:/main.qml")));

sync();

return app->exec();

Обращения к Actions по UUID: (важно, фигурируют только id):

1
2
3
4
5
6
7
App.removeCard(listUuid, cardUuid);
...
App.moveCard(listUuid, drag.source.cardUuid, card.cardUuid);
...
App.addCard(listUuid);
...
App.addList();

Уже на стороне с++ происходит связываение и поиск объектов бизнес-логики, для вызова соответствующих изменений.

Оценка общей идеи

  • Похоже на двусторонние биндинги AngularLight версии 0,8 (до 0.10 включительно). Частично KnockoutJs . Вот функция аналог sync данной библиотеки, это $scan() Angular light https://github.com/lega911/alight_docs/blob/master/docs/source/scope.rst#scopescancallback-or-option
  • Плюсы:
    • позволяет избежать массы лишних отновлений интерфейса
    • позволяет выделить Actions на верхнем уровне
    • нормализует “однанапрвленный поток” данных в приложении
    • позволяет иметь простую (plain old object) модель данных в с++ , не привязывая ее к QML (это, кстати, очень важно). Модели можно применять сборку мусора (управлять памятью произвольно) или даже не иметь ёё а получать QVariantList с сервера и сразу отображать
    • высокая призводительность работы и разработки т.к.
      • нет прокидывания самих моделей в qml как типов
      • не прокидывания сигналов моделей в qml
      • не требуется описывать в моделях свойства и логику работы с ними так, чтобы это было видно в qml
      • на много меньше кода в с++
    • полная управляемость
  • относительные минусы (на самом деле не минусы)
    • надо отмечать все объекты в списках уникальным образом
    • нужно собирать с++ часть. но все это для приложений которые имеют с++ часть
  • минусы
    • все минусы решений типа AngularLight , где контекст сканируется в ручном режиме
      • Если модель большая и много actions , то часто возникают лишние сканирования (в этом случае все нормально т.к. тут патчи перестанут возникать в тех местах где изменений не было.)
      • если данные модели должна зависеть по логике приложения от отображения (например нужно знать реально занимаемые размеры, напрмер высоту), то этот метод уже не подходит или надо разбивать на две части модель (два и более контекстов). Впрочем никакое решение не подходит хорошо в этом случае

Необходимо написать преобразование моделей в QVariantMap, кажется, что это единственная дополнительная работа.

Важно: такое преобразование хорошо сочетается с проектом “сериализатора” который я сейчас делаю. Даже промежуточные классы удачно совпалдии. Суть проекта сериализатора:

Задача: есть plain с++ class | struct с обычными полями и с полями списками (список / вектор). Надо его сериализовать и десериализовать.

предлагается автоматическое решение вида:

  1. специальный консольный инструмент анализирует c++ *.h файл с определением структур и классов.
  2. для классов и структур анализирует структуру (парсит структуру, поля, список итд), генерирует model.json файл, который описывает структуру с++ кода.
  3. консольный генератор по шаблону и с параметрами генерирует для этих классов *.h & *.cpp с сериализаторами и десериализаторами в типы (или из типов), например а) QJsonValue ,) boost::property_tree , которые легко преобразуются в/из строк и или бинарных структур.

т.е. это инструмент разработки, который к обычным прикладным классам добавляет генерируемый по шаблону код, который попадает в проект. скрипт лежит в проекте и обновляет автоматически сгенерированные файлы.

Получается, что в случае использования такого проекта как “генератор сериализаторов по с++ структуре” код перевода модели в QVariantMap даже не потребуется писать.

т.е. в этом случае мы получим

  • чистый с++ код на стороне с++ , не обязательно на QT классах
  • скрипт который сам за нас генерирует все дополнительные преобразоваия наших с++ моделей в промежуточный QVariantMap
  • библиотека (как бы виртуального dom) для оптимального обновления QML модели после анипуляций с с++ данными, которая сама и эффективно синхронизирут с++ модели на qml сторону
  • QML код, который
    • может быть разработан отдельно от приложения
    • работает на JS своих родных моделях
    • не содержит логики верхнего уровня бизнес-логики (обработка actions находится на с++ уровне или в JS скриптах верхнего уровня для тестирования)
    • остается: вся логика которая есть в qml - логика компонентов и отображения (локализованная view логика)

QSListModel - c++ модель для отображения в QML

1
2
QSListModel* cardListStore;
cardListStore = new QSListModel(this);

По сути это помомок QAbstractListModel которого можно “патчить”. Это просто Q_OBJECT

Описание дополнительных удобных методов класса https://github.com/benlau/qsyncable/blob/master/qslistmodel.h#L33 ссылка на строку

JsonListModel

Имеется такая штука как JsonListModel. 

1
2
3
4
model: JsonListModel {
    keyField: "uuid"
    source: cardList.cards
}

Это враппер для синхронизируемых списов… Для отдельных частей единой большой модели.

Зачем:

JsonListModel is a syncable list model.
It could be used as a wrapper of other Javascript array object.
Whatever the source is updated, it will trigger synchronization automatically.
It will emit signals of insertion, removal and moving automatically.

Т.е. это удобная враппер штука, чтобы выделять в данных “подконтексты”, так сказать, которые сами будут обновляться если их родитель обновился.

Важно, что у нее есть свой собственный ::sync()

Underscore.js

https://github.com/diro/qml_underscorejs - Порт популярной блиблиотеки для QML. Underscore это функциональный подход к структурам и потокам.

На фронтенде она удобна для вычисления “частных” отображаемых значений. позволяет просто собрать отображаемое значение, построить JS выражение , котороые вычисляет требуемые данные или находит требуемый объект, фильтрует списки итд.

Документация на исходный оригинал https://underscorejs.org/

Обучаться лучше всего на примерах… или запуская тесты.

Учитывая что QSyncable предоставляет базовые модели с данными а отображение может требовать специальных представлений этих данных - на этой библиотеке могут быть реализованы эффективные вычисления таких представлений. (“силовые” преобразования моделей)

Mobx

На пальцах | concept | site | github | quck example

Эта ссылка - mobx + React - очень полезно понять

Последние новости

Как поиметь это в qml

https://github.com/bhdouglass/qml-browserify - Browserify for QML.

Идея / мысль:

надо Mobx получить в qml в виде JS файла и использовать в своей работе

TODO тут надо сделать это и дописать (не срочно, структура проекта и потоков данных важнее, чем частная реактивность в моделях)

Quickflux - TODO

Линк https://github.com/benlau/quickflux

Правильно сделана структура QML проекта, тут есть чему поучиться, это и сделаем.

Некоторые вещи здесь я буду критиковать, а важное и однозначно полезное выделю.

TODO

Selenium for QML - perfect idea

https://github.com/cisco-open-source/qtwebdriver/wiki/Use-QtWebDriver-to-run-your-application

Данный проект создан для автоматизированного тестирования qml приложений в стиле тестирования веб приложений. Интеграционного тестирования в том числе.

Описываются принципиальные возможности

  1. подключение webDriver к существующему приложению
  2. дайвер сам “создает” приложение

Подключение к существующему приложению - более реалистичная затея.

++:

  • “Проще настроить” :-D
  • жизненный цикл драйвера и приложения связаны

–:

  • перезапуск драйвера вместе с приложением - накладывает сложностина тестирование

но понадобится встроить драйвер в код и влинковать в программу

Способы это сделать:

в результате откроется порт (как минимум)

1
WebDriver driver = new RemoteWebDriver(new URL("http://192.168.24.1:9517"), capabilities);

Созадние приложения из драйвера

++:

  • не надо изменять код приложения… типа

–:

  • драйвер не надо пересобирать
  • можно сделить за циклом приложения при тестировании

Пример с запуском калькулятора https://github.com/cisco-open-source/qtwebdriver/pull/27

Селениум QML Тесты… какие они тут?

В web версии можно спокойно бродить по DOM а тут ? что тут можно из JS ? какие по виду и возможностям будут тесты?

Ответ предположительно такой:

1
2
3
4
5
WebDriver driver = new RemoteWebDriver(new URL("http://192.168.24.1:9517"), capabilities);
// This will trigger creation of a MyWidgetClass
wd.get("qtwidget://MyWidgetClass");
System.out.println("Native page source:\n" + driver.getPageSource());
WebElement elt = driver.findElement(By.xpath("//QTextEdit"));

XPATH … ладно. но я поискал еше примеры:

Итого по “selenium qml”

Жить можно. Сам не пробовал, но возможности, учитывая xpath и работу с аттрибутами и идентификаторами + скриншоты, в целом позволяют делать номальные тесты.