Discussion :

[Fracasse]

Bonjour,

J'ai besoin d'aide et de conseil pour mon développement actuel.

Je me suis lancé pour développer une STAN (Daw), l'idée est qu'elle soit multi-platforme, mais surtout implémentable dans un système embarqué à l'avenir. Ainsi, pour me "simplifier" la tâche, j'ai choisi le C comme langage principale.
Mais, puisque mon premier objectif est de développer l'application sous Windows avec des fenêtres "esthétiques", j'ai choisi QT comme bibliothèque. Cela implique d'utiliser le C++. Cette idée ne me disconvient pas à partir du moment que cela servira d'interface, sans affecter, a priori, le moteur du logiciel qui sera en C.

Je suis cependant face à des questionnements quant à l'interfaçage du GUI et du moteur du logiciel.

Je ne suis pas un développeur pro, mais amateur, avec une bonne connaissance du développement C en mode console, mais sais aussi développer en C++, mais je n'ai jamais développé d'application avec fenêtre, du coup, j'ai dû mal à me représenter les choses, je veux dire : 1) définir l'architecture sous forme de diagramme de cette séparation GUI - moteur, et 2) concrètement, comment répondre à une action utilisateur une fois que le GUI passe la main au moteur.

Je sais créer des API en C et C++, mais du coup, comment se passe les transitions GUI - moteur (en supposant QT) ?

Est-ce que quelqu'un pourrait me donner des conseils sur une telle architecture logiciel (des exemples précis serait plus que bienvenus) ?

Je précise que ce n'est pas un développement "commercial", pour moi et peut-être diffuser gratuitement sous forme oppen-source et j'ai du temps à y consacrer...

[LittleWhite]

Bonjour,

Globalement, lorsque l'utilisateur effectue quelque chose sur l'interface, Qt appelle une fonction que vous implémentez. Plus précisément, dans le monde de Qt, vous avez des signaux (envoyés lorsque l'utilisateur fait quelque chose, ou par l'application) et vous connectez aux signaux, des slots, des morceaux de code à exécuter lorsque le signal est émis.

Pour l'architecture de l'application, c'est assez compliqué. Mais généralement, on se rapproche souvent du design MVC (Modèle, Vue, contrôleur). En bref, votre interface graphique va quérir les informations à afficher de votre moteur et va appeler votre moteur pour faire évoluer l'état (et si on est attentif, ce design là n'a pas vraiment de séparation entre le modèle et le contrôleur). Après, dit comme ça, le couplage risque d'être assez important. Du coup, vous pourrez mettre en place un système de... signaux, ou autre, pour envoyer des messages et recevoir des réponses de votre moteur.

Mais, je vous conseille d'abord de commencer et d'être prêt à commencer plusieurs fois, pour comprendre et apprendre à faire le design qui convient le mieux pour votre cas. Au début, il ne faut pas créer une solution trop complexe, car sinon, l'application ne voit jamais le jour .

[Sve@r]

Bonjour

Je me suis lancé pour développer une STAN (Daw), l'idée est qu'elle soit multi-platforme, mais surtout implémentable dans un système embarqué à l'avenir. Ainsi, pour me "simplifier" la tâche, j'ai choisi le C comme langage principale.

C pour du multiplateforme ???

Mais, puisque mon premier objectif est de développer l'application sous Windows avec des fenêtres "esthétiques", j'ai choisi QT comme bibliothèque. Cela implique d'utiliser le C++. Cette idée ne me disconvient pas à partir du moment que cela servira d'interface, sans affecter, a priori, le moteur du logiciel qui sera en C.

Hum... Alors C++ ce n'est pas C. Ca ne marche pas ensemble.
Toutefois si tu écris du C super propre, super rigide, super correct alors tu peux le faire compiler par un compilateur C++. Et de là tu le nommes ".cpp" et ça devient du C++.

j'ai dû mal à me représenter les choses, je veux dire : 1) définir l'architecture sous forme de diagramme de cette séparation GUI - moteur, et 2) concrètement, comment répondre à une action utilisateur une fois que le GUI passe la main au moteur.

Le GUI ne passe jamais la main à qui que ce soit. Il la garde tout le temps.
En MVC on a l'impression que les 3 notions sont plus ou moins au même niveau mais en réalité, le GUI est plutôt une espèce de "tour de contrôle". C'est dû au fait qu'il démarre en boucle infinie, traite les évènements (boutons, cases, zones textes) et quand la boucle se termine, le programme se termine avec.
Mais rien n'interdit à une fonction du GUI d'appeler une fonction de ton moteur. C'est du GUI mais ça reste du C++. Ainsi "V" appelle "C".

Est-ce que quelqu'un pourrait me donner des conseils sur une telle architecture logiciel (des exemples précis serait plus que bienvenus) ?

Tu peux aller voir mes exemples Qt. Juste que ce sont des exemples Python (donc PyQt). Après j'ose croire que traduire un objet Python en C++ n'est pas super compliqué...