Discussion :

[francky380]

Bonjour à tous,

Je viens de terminer (enfin du moins une V1.0 on va dire, rien n'est jamais vraiment terminé) une application sous Python utilisant:
- Python 3.X
- PyQt5 (GUI)
- QDesigner (mise en forme de la GUI)
- Matplolib (graphiques)

Son but : Faire ses comptes simplement et donner à l'utilisateur plusieurs outils d'analyse, notamment grâce à des graphiques (pas moins de 13 différents).

L'application fonctionne bien, malgré quelques temps longs lorsqu'il faut mettre à jour les 13 graphiques "en même temps". En effet, lorsque j'ajoute une transaction à mon compte, je peux décider de mettre à jour tous les graphiques et cela prend du temps.

Ma question est la suivante: Quelle est la façon la plus optimal de gérer les données, les graphiques, l'interface etc ?

Aujourd'hui l'application se présente ainsi:

- Une QMainWindow (home) qui liste les comptes déjà créé et qui permet d'en charger un ou bien d'en créer un nouveau. Elle ne contient pas d'information ou de grosses structures
- Un QDialog par compte ouvert. Ce QDialog contient toutes les informations, toutes les structures et toutes les fonctions nécessaires associé à un compte.

Je me demande donc si ma façon d'opérer est la bonne et si c'est la plus optimisée ?

Je trouve que le QDialog contient peut-être trop d'informations, trop de données, trop de fonctions et que cela ralenti l'exécution de l'application. Actuellement je n'utilise aucun QThread par exemple, tout se fait dans la Main Loop, ce qui, je sais, n'est pas forcément très bien. Or, j'ai 13 graphiques et chaque appel de la fonction 'draw()' doit se faire au sein de la Main Loop si j'ai bien compris et c'est là que je perds beaucoup de temps. Le traitement des données en lui-même se fait rapidement car les structures ne sont pas très lourdes (dictionnaires, liste, table, etc.).

Pour exemple, j'ai un dictionnaire contenant 12 ou 16 sous-dictionnaire contenant chacun 13 et 20 valeurs. C'est la plus grosse structure de donnée que je pourrais avoir.

Je me demande donc si je ne devrais pas séparer ainsi mes objets:

- Une QMainWindow (home). Même fonctions que précédemment.
- Un QDialog par compte ouvert. Ce dernier servirait uniquement d'interface avec l'utilisateur. Il tracerait les graphiques et afficherait les informations qu'on lui envoie.
- Un objet de stockage de données par compte ouvert. Dans cet objet j'y stockerais les données et j'y effectuerais les calculs lorsque j'ajoute une transaction ou que j'en supprime une. Il renverrais les informations vers le QDialog
- Un couple thread/worker par grosse fonction. Ces fonctions là récupèrent les données dans les dictionnaires et autres listes (de l'objet de stockage), font les calculs (sans ajouter, ni supprimer de données) et renvoient des listes et des données à afficher (grâce matplotlib dans le QDialog).

L'objet de stockage sera créer à l'intérieur du QDialog pour pouvoir communiquer facilement les données. De même pour les couples thread/worker. Finalement le QDialog contiendra toujours beaucoup d'information, mais ces dernières seront peut-être mieux segmentées.

Qu'en pensez-vous ?

Merci d'avoir pris le temps de me lire et peut-être de me répondre

[VinsS]

Salut,

Il se dégage deux impressions de ce que tu expliques.

1. Tu utilises essentiellement une QDialog pour le travail principal et une QMainWindow pour ne faire que de l'affichage de données.

Ce devrait être la QMainWindow l'interface avec laquelle l'utilisateur communique, entre ses données, les édite, etc. Un QDialog est un objet éphémère qui ne sert qu'à un évènement ponctuel; Confirmer une opération, Avertir d'une erreur, etc.

Pour placer la gestion de différents comptes dans des widgets distincts tu as le QTabWidget ou encore le QStackedWidget.


2. Ton code n'existe que par ses widgets alors qu'il devrait en être totalement séparé.
Donc il devrait être dans un script séparé qui récupère les évènements de l'interface, prépare ce qui est demandé par l'utilisateur et envoie les nouvelles données à l'interface dont le rôle n'est que de l'affichage.
Un peu comme ces lecteurs audio pour voiture dont la face avant est amovible, cette face n'est qu'un objet de communication et d'affichage, le vrai travail est réalisé dans le boitier de l'appareil.

[francky380]

Salut,

Il se dégage deux impressions de ce que tu expliques.

1. Tu utilises essentiellement une QDialog pour le travail principal et une QMainWindow pour ne faire que de l'affichage de données.

Ce devrait être la QMainWindow l'interface avec laquelle l'utilisateur communique, entre ses données, les édite, etc. Un QDialog est un objet éphémère qui ne sert qu'à un évènement ponctuel; Confirmer une opération, Avertir d'une erreur, etc.

Pour placer la gestion de différents comptes dans des widgets distincts tu as le QTabWidget ou encore le QStackedWidget.


2. Ton code n'existe que par ses widgets alors qu'il devrait en être totalement séparé.
Donc il devrait être dans un script séparé qui récupère les évènements de l'interface, prépare ce qui est demandé par l'utilisateur et envoie les nouvelles données à l'interface dont le rôle n'est que de l'affichage.
Un peu comme ces lecteurs audio pour voiture dont la face avant est amovible, cette face n'est qu'un objet de communication et d'affichage, le vrai travail est réalisé dans le boitier de l'appareil.

Merci Vins, c'est exactement ça !

1. Oui, en effet. J'avais lu qu'on ne pouvait pas avoir plusieurs QMainWindow, donc j'en ai créé une, qui est la première que l'on voit, les autres allaient être des Qdialog. L'option du QStackedWidget me semble la plus adapté, merci.

2. Oui, c'est également le cas. Pas de widget = pas de code. Ce qui n'est pas une bonne chose puisque chaque widget va reprendre le même code, il me suffit donc de créer ce tron commun dans un code à part.

Les données, les traitements, la présentation des résultats/données sous forme de graphiques, et les interactions avec l'utilisateur sont des domaines assez différents.
Et techniquement, ne serait-ce que pour pouvoir tester, optimiser,... on essaie de les réaliser indépendamment.
Bien sûr, à la fin, il faut pouvoir intégrer tout çà et que çà se cause mais c'est d'abord une question d'interface entre les différents composants de l'application.

Là, vu comment vous racontez votre application, on dirait que tout est structuré autour l'interface utilisateur alors que c'est juste un "accessoire".

- W

Merci wiztricks,

C'est bien vu en effet, c'est exactement ça également. Je m'y suis un peu mal pris.

En conclusion de ce que je viens de lire:

Je vais avoir mes fichiers produits par QtDesigner
Je vais avoir un fichier pour les interfaces (home + UI(s))
Je vais avoir un fichier avec le code (stockage + traitement + calcul)

C'est bien cela ?

Dans le fichier interface, je vais construire mes interfaces et implanter les fonctions d'affichage. Principalement donc des draw(), setText() et addItem() au besoin.
La meilleur façon de communiquer avec le fichier de code sera d'utiliser des PyQtsignal, PyQtSlot ? avec les méthodes emit() ?

Dans le fichier de code, je créer un object qui va stocker et traiter les données ? Dois-je séparer le stockage et le traitement ? Je pensais faire un objet par "grosse" fonction pour pouvoir utiliser des couples thread/worker. Donc finalement un worker = une fonction et je le moveToThread() ensuite.

Quel objet devrait être parent de quel objet aussi ?

[wiztricks]

Salut,

La meilleur façon de communiquer avec le fichier de code sera d'utiliser des PyQtsignal, PyQtSlot ? avec les méthodes emit() ?

La seule chose que vous pouvez faire avec un module, c'est "import".

Slot et Signaux sont des mécanismes de communication entre QObjects.

Le mécanisme de communication de base entre 2 objets "normaux" est l'appel de méthode.

- W

[francky380]

Salut,



La seule chose que vous pouvez faire avec un module, c'est "import".

Slot et Signaux sont des mécanismes de communication entre QObjects.

Le mécanisme de communication de base entre 2 objets "normaux" est l'appel de méthode.

- W

D'accord, très bien, je comprend.

Je viens de voir qu'il est utile de basé sa GUI sur le modèle MVC (Model View Controller). Chose que je ne connaissais pas jusque là. Basiquement cela reprend bien ce que vous aviez dit précédemment, séparer chaque fonction. Le controller fait le lien entre le Model et la View.

Conclusion : Utiliser le modèle MVC

Je pense que vous aviez bien répondu à ma question, merci.

[wiztricks]

Salut,

Qu'en pensez-vous ?

Les données, les traitements, la présentation des résultats/données sous forme de graphiques, et les interactions avec l'utilisateur sont des domaines assez différents.
Et techniquement, ne serait-ce que pour pouvoir tester, optimiser,... on essaie de les réaliser indépendamment.
Bien sûr, à la fin, il faut pouvoir intégrer tout çà et que çà se cause mais c'est d'abord une question d'interface entre les différents composants de l'application.

Là, vu comment vous racontez votre application, on dirait que tout est structuré autour l'interface utilisateur alors que c'est juste un "accessoire".

- W