Logique programmation PyQt

Bonjour à tous,

J'ai actuellement un programme python qui récupère des trames GPS, interprète l'appuie sur deux boutons poussoirs et récupère aussi les datas de quelques capteurs, pas de soucis de ce côté là.

Je voulais faire une petite interface graphique de tout ça, en fouillant Qt, et donc PyQt revenait régulièrement. Comme il a un IDE pour créer l'interface c'est quand même un gros plus. Bref, je pensais que le principe était de créer son interface, d'ajouter le code de l'interface dans mon code et quand j'ai besoins d'afficher les infos j'appel une fonction pour mettre à jour un champ texte, une couleur etc....
Sauf que j'ai fais quelques essais et fouillé un peu, ça ne semble pas du tout marcher comme ça, l'interface graphique devient en quelques sortes le programme principale. Une fois l'interface affichée, je peux plus avoir mon code habituel qui récupère les infos des capteurs...

Qu'elle est donc la logique de programmation avec Qt, sachant que je dois faire les actions suivantes :

Lire des trames GPS toutes les 100mS, en récupérer la vitesses pour l'afficher dans l'interface graphique.
Afficher des chronos sur l'interface graphique
Récupérer les valeurs de capteurs, type potard, T°, et les afficher
Interpréter l'appui sur des boutons poussoirs.
En plus de l'interface graphique, je dois pouvoir envoyer toutes les infos ci dessus vers une BDD distante. (Je suis sur un raspberry pi connecté en wifi, pour enrichir la BDD ca sera via des requêtes HTTP)

Je suis donc un peu perdu, et je ne vois pas trop l'architecture à utiliser avec Qt, pouvez-vous m'aiguiller ?
Actuellement, sans GUI, j'ai une grosse boucle while qui va chercer les infos du GPS, des capteurs etc et stock tout ça dans un fichier texte.

Merci :)


Merci pour votre aide.

Salut,

Citation:

---

Envoyé par H3xor

Qu'elle est donc la logique de programmation avec Qt

---

La logique de programmation avec Qt est la même qu'avec n'importe quelle autre bibliothèque permettant la réalisation d'une interface utilisateur graphique(GUI): c'est une programmation évènementielle très différente de la programmation séquentielle qu'on apprend lorsqu'on débute.

Et techniquement vous avez deux solutions:

• vous ré-écrivez votre code pour qu'il soit compatible avec cette programmation évènementielle en utilisant des "timers" qui se déclencheront toutes les 100ms pour récupérer des infos,...
• vous poussez le code dans un thread qui pourra s'exécuter indépendamment (interface graphique ou console) mais vous allez avoir à définir une interface (et revoir votre code existant) pour arriver à le commander depuis l'interface graphique/console.

Donc ce n'est pas "simple" vu tout ce qu'il y a à maîtriser avant de s'y lancer.

- W

Hm, ok, je vois.

Est-ce qu'il y a une méthode préférée entre les timers et les threads ? (C'est au libre choix du dev' qui prend la méthode qu'il préfère ? Certains contextes font que l'on va préférer une méthode ou une autre ?)

Citation:

---

Envoyé par H3xor

Est-ce qu'il y a une méthode préférée entre les timers et les threads ?

---

Techniquement, les threads sont à préférer lorsque vous n'avez pas le contrôle de la durée des opérations effectuées, car dans ce cas, le GUI se gèle tant que l'opération n'est pas terminée.

En dehors de ce cas là, le choix est arbitraire.
Dans la logique "je construis quelque chose", il me paraît plus judicieux d'avoir un thread qui permet de tester la partie GPS de l'application avec des commandes simples et de peaufiner l'interface (technique) puis de fabriquer l'interface utilisateur.
Ça permet de séparer les difficultés... mais c'est "mon" point de vue, vous pouvez très bien tout mélanger.

- W