Structure d'un projet conséquent avec PyQt

Bonjour, J’apprends à utiliser PyQt et QtDesigner,
dans l’optique de créer un petit logiciel un peu plus complexe que ce qui suit, et surtout maintenable à long terme.
Pour l’instant, j’arrive à un résultat plutôt satisfaisant, j’ai pu créer un petit script de ToDo List à catégories,
très simple en utilisant quelques widgets de type (QTabWidget, QTableWidgetItem, QStackedWidget, QDialog, quelques widgets sympa et quelques layouts)
Avec une structure type Model-View très simple comme celle qui suit:
(Pas celle expliquée dans la doc de QT, car je n’utilise pas encore les "widgets models based")

1
2
3
4
5

- Models # Models/Manager, Task/Category, avec Django "Standalone"
- Views
    - View Principale # qui se charge de tout ou presque, signaux, set/get datas dans la GUI
    - View Formulaire # (QDialog) Ajouter/Modifier/Supprimer:[Tâche/Catégorie]
- GUI # les fichiers GUI de QT compilé avec pyuic

Une fenêtre == Une classe, ça fonctionne bien c’est sympa,
Mais j’en doutes fort pour un projet d’envergure (Fichier très long).
Donc voici ma question comment organiser un code en MVC ?
Jusqu’où dissocier les controllers/views ?

Faire un controller/view pour chaques widgets ?
Et à partir de quel type de widget baser le MVC ?
- type layout (ex: QverticalLayout) ?
- ou type container (ex:QStackedWidgetItems)?
- ou type data(ex: QLineEdit) ?
- ou au choix (selon le contexte)?

J’ai commencé à faire un petit essai en MVC et étant un adepte de la philosophie DRY
j’ai été un peu décontenancé par la lourde répétition qu’imposer ce pattern.

Après avoir lu plusieurs topic, j’ai un peu l’impression que les patterns proposés, sont soit MV soit à la bonne franquette ?!

Si quelqu’un connaît un dépot en Python/PyQt un peu complexe, car je ne trouve que de petits scripts d’exmple très peu fourni.

Merci d’avance m’avoir lu

Salut,

En général, je laisse tomber ce genre de “design patterns”.

Je m’explique. Pour moi, séparer la vue du modèle c’est pratiquement toujours bien, mais un contrôleur ne fait pas toujours beaucoup de sens. Souvent, quand on essaye de faire du MVC à l’ancienne, on se retrouve au final avec un fouillis pas possible à base d’event listeners et de modèles et de vues muables (avec pleins de bugs). Ce qui marche côté serveur ne marche pas toujours bien côté client.

Dans le monde de l’interface graphique, il y a deux autres façons de faire que j’ai expérimenté :

• Le MVVM. AngularJS utilise ça. C’est une sorte de MVC un peu adapté, mais ça reste quand même quelque chose de très muable (au moins dans le cas d’AngularJS), et j’en garde un assez mauvais souvenir.

• La philosophie complètement opposée de React, Cycle, Elm et companie. Le principe est très simple : Le “contrôleur” est une fonction pure qui prends le modèle en paramètre et qui retourne la vue. Tout peut être immuable, le modèle comme la vue. On peut aussi se passer d’inscrire et de désinscrire des event listeners à tout va et c’est très testable. J’adore cette façon de faire.

Bon, tout ceci n’est probablement pas utilisable avec Qt. Voici mes conseils :

• Écrit des tests. À long terme, c’est indispensable, vraiment.

• Les principes du genre “Une fenêtre == Une classe”, c’est très mal. Typiquement, certaines fenêtres seront ridiculeusement simples (boîtes de dialogues avec un bouton “OK”), d’autres très compliqué. Pour moi, il faut pouvoir créer de simples boîtes de dialogue avec une simple fonction et découper les fenêtres compliquées en plusieurs fichier.

• Ne cherche pas à faire du MVC. Si dans un cas, un modèle et/ou un contrôleur ne fait pas de sens, n’en fait pas, ça compliquerait probablement les choses pour rien.

• Essaye de rendre (ou considérer) certains de tes objets comme immuables si possible. Avec Qt, ça risque de ne pas être évident à faire mais je pense que ça peut éviter pas mal de bugs.

Je le redis au cas où : Écrit des tests. À long terme, c’est indispensable, vraiment.

Je rajoute : Documente. À long terme, c’est indispensable, vraiment.

Sinon pour continuer un peu. Cherche pas à coller à un pattern. Cherche surtout à faire un truc compréhensible pour tous et simple à comprendre.

Je connaissais pas le MVVM, mais rien qu’à en lire l’avis de son créateur, ça donne pas envie de l’utiliser.
Alors autant je documente relativement bien mon code mais alors les tests… (j’en ai même jamais fait )

Oui, évidemment, mais quand j’ai dit "Une fenêtre == Une classe, ça fonctionne bien c’est sympa"
C’était sur le ton ironique

Oui, c’est justement pour ça que je voulais utiliser un pattern, pour "normaliser" le code,
afin d’avoir une logique code qui puisse être comprise par tous (Qui implique tout de même d’avoir compris le pattern).
Donc je pense que je vais aller au plus simple, sans tortiller d…

À propos de l’immuabilité, je ne suis pas sur d’avoir compris le principe.
Quand on dit d’un objet qu’il est immuable,
Le terme immuable prend effet à partir de la phase de création de l’objet ou post-création ? c’est à dire l’utilisation de l’objet ?

Toute façon, là je suis en train de continuer ma première application avec PyQT,
pour continuer de m’habituer avec les fenêtres et je la mettrai sur GitHub, pour avoir des critiques sur l’organisation etc…