Cavoke Client (прототип)

Максимально упрощенный клиент, запускающий QML приложения.

Функциональность

Пока что сделано:

• Динамический запуск QML из C++ из ресурсов (Саша)
• Двусторонний обмен данными QML <--> C++ (Саша)
• Отрезать логику крестиков-ноликов от QML и подключить к C++
• Загрузка данных для обмена в файл/из файла (альтернативно из TextEdit)
• Подгрузка QML по переданному абсолютному пути (см. QFileDialog и пример)
• Загрузка QML из Zip (?) файла в какой-то кеш (QStandardPaths)
• ... (см. статус документ)

Как запустить

1. Загрузить Qt: https://doc.qt.io/qt-6/get-and-install-qt.html. Он будет весить много (потенциально > 5гб).
2. Установить KArchive:
   1. Склонировать extra-cmake-modules: https://github.com/KDE/extra-cmake-modules, собрать cmake-ом
   2. Склонировать KArchive (важно: версии не меньше, чем extra-cmake-modules): https://invent.kde.org/frameworks/karchive, собрать cmake-ом
3. Открыть проект и запустить
4. Выбрать путь к основному qml файлу приложения либо выбрать .zip архив, в корне которого будет лежать app.qml файл с приложением
5. Открыть панель с выводом приложения. Убедиться, что соединение между C++ и QML работает.

Комментарии

Про архитектуру клиента (04.02.2022 Саша)

Терминология

• move -- то, что отправляет QML серверу. Таким образом у QML сигнал sendMove
• update -- то, что сервер отправляет QML. У QML слот receiveUpdate

Про MVC и общую структуру

Я решил прототип сразу сделать каким-никаким MVC. Это несколько нагромождает, но упрощает дальнейшую разработку, чтобы об это потом не спотыкаться.

• View отвечает только за отображение MainWindow (то где только кнопка TicTacToe)
• Controller отвечает за связь View и Model (чтобы View не висла, когда Model что-либо делает), а также за запуск QML подприложений.
• Model отвечает за связь с сервером (пока что с файлом).

В Model есть ещё класс CavokeQmlGameModel. Он в сущности контроллирует инстанс qml -- именно к нему подключены сигналы/слоты у QML.

Почему нельзя было подключить QML напрямую к Model? Потому что сигнал нужно подключать напрямую, а значит если Model хочет отправить update одному QML, то пришлось бы триггерить все (и/или дополнительный код для пользователя). Поэтому сделал такой контроллирующий объект для каждого QML.

Про утечеки памяти

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