Utilisation d'une extension

Bonjour à tous =)

Voilà plusieurs jours que je me débat avec QtQuick pour commencer un petit projet : je mets un point d'honneur à ce que tous mes composants soient réutilisables, et donc je les développe dans une bibliothèque à côté du projet principal.

Mes souhaits sont :
1) Développer les UI en QML
2) La logique en C++
3) Ce qui implique que j'utilise qmlRegisterType sur les classes en relation avec la logique. J'aimerais donc si possible, que le module "logique" dans lequel seront mises toutes ces classes, soit dissocié du module "controls", qui m'offrira simplement la possibilité d'utiliser les composants "UI".

Pour cela, développer un extension plugin m'a semblé correct. Pour l'instant, je ne travaille qu'avec un seul module, "controls". Mais depuis mon projet principal, dans mon main.qml, QtCreator ne reconnaît pas mon type QML (qui correspond à un fichier .qml), mais uniquement le binding QML de la classe de logique (understand ? x) ). Pourtant, l'exécution se déroule normalement.

Mon fichier controls.pro copie les fichiers .qml et le qmldir dans le répertoire de build. Le dossier parent fait partie des répertoires d'import du système QML.

Je vous joins une capture d'écran, vous comprendrez un peu mieux je pense.

Ou alors, un extension plugin n'est pas approprié à ce que je veux faire ?
Ce que je souhaite faire dans mon 3) est-il possible ?

Merci à tous :?

Pièce jointe 155114

Bonjour,

Dans le sens où l'exécution se produit normalement, je pense que ce qu'il vous manque est un fichier qmltypes à côté de votre qmldir, tel qu'indiqué ici : http://doc.qt.digia.com/qtcreator-2....h-plugins.html
Dans votre qmldir, vous devrez alors ajouter typeinfo plugins.qmltypes pour un fichier qmltypes nommé plugins.qmltypes situé à côté du qmldir.
Est-ce fonctionnel dans votre cas ?

Bonne journée à vous,
Louis

Bonjour et merci pour ta réponse =)

J'ai généré le .qmltypes avec qmlplugindump :
qmlplugindump controls 1.0 > controls.qmltypes

Que j'ai placé aux côtés du qmldir.

Mais cela ne fonctionne pas. Selon le contenu du .qmltypes, il semble que GridMenu.qml ne soit pas considéré comme appartenant au module "controls". Pourtant, il fait bien partie de l'extension plugin. Ou alors je n'ai pas saisi une subtilité.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

// controls.qmltypes Module { Component { name: "GridMenuLogic" prototype: "QObject" exports: ["GridMenuLogic 1.0"] exportMetaObjectRevisions: [0] Signal { name: "itemSelected" Parameter { type: "string" } } } }

---

C'est étrange qu'il n'y ait pas les fichiers .qml dans le fichier généré. Vous avez exécuté le script dans quel dossier ? Quelle est votre arborescence ? Et quelle est votre version de Qt Creator ?

Bonne journée,
Louis

J'utilise QtCreator 3.2.0 (la dernière).

Je n'ai pas de dossier "import", il ne m'a pas semblé obligatoire =/

Voici l'arborescence de ma lib, qtquick est un projet de sous-dossiers, controls est le projet d'extension plugin :

qtquick
- qtquick.pro
- controls // J'ai exécuté qmlplugindump dans ce dossier
--- controls.pro
--- controls_plugin.(h/cpp)
--- gridmenulogic.(h/cpp)
--- GridMenu.qml
--- qmldir
--- controls.qmltypes

Et quel est le contenu de votre nouveau fichier qmldir ? Il me semble que vous respectez bien la ressource http://qt-project.org/doc/qt-5/qtqml...ppplugins.html donc je ne saurais trop dire pour le moment.

Bonne soirée,
Louis

Voici :

Code:

---

1 2 3 4 5 6 7

// qmldir module controls GridMenu 1.0 GridMenu.qml plugin controls   typeinfo controls.qmltypes

---

Bonsoir,

Si vous mettez ceci dans votre qmldir :

Code:

---

1 2 3

module controls plugin controls typeinfo controls.qmltypes

---

Et que vous lancez la commande suivante :

Code:

---

qmlplugindump -nonrelocatable controls 1.0 > controls.qmltypes

---

Quel est le résultat ?

Bonne soirée,
Louis

Le contenu du fichier est identique à celui que j'ai posté avant, excepté la ligne :

Code:

---

exports: ["GridMenuLogic 1.0"]

---

qui change pour

Code:

---

exports: ["controls/GridMenuLogic 1.0"]

---

Si je laisse comme ça, GridMenu n'est pas reconnu à l'exécution.

Et que donne la même procédure avec ce qmldir-ci ?

Code:

---

1 2 3 4

module controls plugin controls GridMenu 1.0 GridMenu.qml typeinfo controls.qmltypes

---

Une autre possibilité serait d'écrire le qmltypes à la main (pas forcément génial, mais je n'ai pas trop d'autre solutions).
Dernière question : est-ce que vous avez essayé de relancer votre QtCreator à chaque nouvel essai ?

Bonne soirée,
Louis

Même résultat. J'ai même fais la série "Nettoyer/qmake/Compiler", j'ai restauré le modèle de code QML...

Je vais essayer d'écrire le fichier à la main, merci à toi =)

Étrange...

Si ça peut vous aider, pour un Label.qml, un composant dont la base est un simple Text, cela donne ceci :

Code:

---

1 2 3 4 5 6 7 8

Component { prototype: "QQuickText" name: "QtQuick.Controls/Label" exports: ["QtQuick.Controls/Label 1.0"] exportMetaObjectRevisions: [0] isComposite: true defaultProperty: "data" }

---

Bonne soirée,
Louis

Ah merci beaucoup, je manquais de doc sur le sujet.

Tant que j'y suis, crois-tu que placer les classes de logique dans un module à part soit approprié ?
Et est-ce possible, dans le cas de l'extension plugin ? (un module pour la logique, un module pour les composants qml)

Tout dépend des besoins : si l'objectif est de pouvoir fournir des mises à jour, cette séparation peut être intéressante. Pour ma part, je préfère séparer mes plugins de manière fonctionnelle et non sur le plan core/gui. Par exemple, si je développe un système de fenêtre personnalisée avec un design propre, je ferais un plugin pour la fonctionnalité elle-même et non un pour la logique se situant derrière et un pour l'interface graphique. Pour un jeu où on aurait côté graphique un fichier Unit.qml et toute une logique à côté, je ferais également un plugin. Il me semble que c'est d'ailleurs sur ce principe qu'est développé Qt Creator : il est constitué d'un grand nombre de plugins représentant une fonctionnalité.

Le fait que je passe à une sorte de...MV...s'explique (ou s'expliquait car ton raisonnement tient beaucoup mieux) par le fait que j'ai une aversion pour Javascript. Voilà pourquoi je cherche à séparer logique (c++) de l'ui (qml).

Mais mettre toutes les classes de logique dans un module, en C++ et même en conception, je n'ai vu ça nulle part :aie:

Et puis bon, JS est présent pour un paquet d'années encore...donc je vais prendre sur moi-même :aie:

Donc au final...un seul module. C'est noté. Mais utiliser un binding pour la logique de GridMenu est donc sensé ?

Je peux éventuellement faire un retour sur expérience dans ce cas.

Pour ma part, je développe en ce moment un petit jeu avec QML pour lequel l'intégralité de la logique est développée du côté du C++. Je préfère ne pas utiliser les listes JavaScript pour stocker mes unités, par exemple, car les manipulations de ces dernières sont relativement coûteuses en comparaison avec les listes C++. De même, pour ce qui est des différentes opérations, calculs, etc., je préfère passer par le C++ et garder uniquement le QML avec le moins d'expressions JS possible dedans.

Pour illustrer cela, je vais prendre pour exemple mon affichage cartographique.

Du côté C++, je possède deux classes : une classe Map et une classe Tile. Ma classe Map, de type QObject, instancie les Tiles, également de type QObject, la constituant selon la carte à charger. Elle possède dans ses public slots une méthode Tile *getTile(const QPoint &pos) qui retourne la case située à la position passée en paramètre, ainsi qu'un certain nombre de méthode utilitaires telles que void move(Unit *who, const QPoint &pos) qui déplace une unité d'une position à l'autre. Elle contient également deux Q_PROPERTY de type int nommée mapWidth et mapHeight. Quant à elle, la classe Tile possède notamment une Q_PROPERTY de type QString nommée texture ainsi que quelques slots utilitaires. Les slots sont déclarés au moc, et donc sont accessibles depuis le QML.

Du côté de l'interface graphique, un élément QML nommé Map.qml possède trois propriétés, mapObj, mapWidth et mapHeight, ainsi qu'un Repeater ayant pour model mapWidth * mapHeight et pour delegate un composant Case.qml représentant une case de la carte.

Map.qml

Code:

---

1 2 3 4 5 6 7 8 9 10

Item { property QtObject mapObj: null property int mapWidth: mapObj ? mapObj.mapWidth : 0 property int mapHeight: mapObj ? mapObj.mapHeight : 0   Repeater { model: mapWidth * mapHeight // etc. } }

---

De son côté, le composant Case.qml est une Image possédant une propriété tileObj :

Code:

---

1 2 3 4 5

Image { property QtObject tileObj: null source: tileObj ? tileObj.texture : "" // etc. }

---

Lorsque l'interface graphique est chargée, via un Component.onCompleted, j'appelle un unique code JavaScript qui va appeler une méthode C++ createMap() d'une instance d'une classe Game exposée à QML en tant que contextProperty, puis je relie chaque objet C++ à l'objet QML :

Code:

---

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

class Game : public QObject { Q_OBJECT public: ... public slots: Map *createMap() { /* Crée une Map, la charge depuis des fichiers, etc. puis la retourne */ } };   // main.cpp   int main(...) { ... Game g; view.rootContext()->setContextProperty("gameHandler", &g); }   // main.qml :   Component.onCompleted: { mapArea.mapObj = gameHandler.createMap(); for (var y = 0; y < mapArea.mapHeight; ++y) for (var x = 0; x < mapArea.mapWidth; ++x) { var tile = mapArea.caseAt(x, y); // fonction JS de Map.qml utilisant itemAt() du Repeater pour retourner la case à la position (x ; y) if (tile) tile.tileObj = mapArea.mapObj.getTile(x, y); } }

---

Et c'est tout pour la carte. À partir de là, mes objets QML ont accès à mes objets C++ et peuvent en appeler les méthodes. Quand par exemple la propriété "texture" d'une Tile change de valeur, elle va émettre son signal NOTIFY et le QML va comprendre tout seul qu'il doit mettre à jour l'image de l'élément Case.qml associé.

Voilà comment je procède.

En espérant vous avoir éclairé,
Louis

Merci beaucoup pour cet exemple, je comprends mieux.

Une autre question que je me pose, c'est au niveau du coût mémoire d'un QObject.
Même si les ordis aujourd'hui disposent d'une quantité considérable de RAM, admettons que ta map est démesurément grande, vu que Tile hérite de QObject, la mémoire ne va-t-elle pas exploser ?

Personnellement, j'aurais donné à Map la possibilité de retourner la texture d'une de ses Tile de façon à ce que le code QML puisse les dessiner.

Qu'en penses-tu ?

En terme de consommation de RAM, le plus lourd, c'est plutôt les fichiers (notamment les textures). Les QObject ne prennent que quelques octets, ce qui est négligeable en comparaison avec les centaines de ko des images. Après, dans mon cas, mes maps font du 15x15 en général, et mes tiles du 50x50px, donc je n'ai pas ces problématiques. Dans le cas d'une map énorme où le joueur pourrait se promener (par exemple un jeu 3D, ce genre de chose), votre proposition serait parfaitement justifiée, mais elle priverait de l'actualisation dynamique des propriétés et forcerait à avoir des fonctions de mise à jour.

Ok merci.

J'aurais une requête : chez toi, qmlplugindump prend-il en compte les fichiers .qml ? Car j'ai testé sur un projet vide avec un extension plugin basique et ce n'est toujours pas le cas.

J'ai testé tout à l'heure et rien à faire, ça ne prend que les extensions avec leurs méthodes associées mais pas les .qml. Cependant, le qmldir devrait être suffisant, en théorie, d'où mon incapacité à répondre à cette question. Par contre, je vais partir en déplacement un bon bout de temps, ce qui fait que je ne pourrai plus intervenir sur cette discussion. Je laisse qui le souhaite prendre la main, par conséquent.

Bon courage à vous pour votre projet,
Louis

Merci à toi ! A la prochaine.

Bonjour,
En lisant ton exemple Amnell, je me suis demandé pourquoi tu ne crées pas ton propre Model en c++ (basé sur QAbstractItemMode ou autre) ?

Je vais utiliser le "paradigme" des context properties. Merci beaucoup à toi de m'avoir éclairé sur le sujet, ça ressemble déjà plus à du MV que le concept de l'extension plugin (après tout, je n'ai pour l'instant aucune classe qui ait besoin d'être accessible plusieurs fois par QML).

A présent, voyons voir comment accéder à des fichiers .qml "publics" depuis un fichier .qml situé dans un qrc :aie: