Discussion :

[Sve@r]

ici c'est un problème de design ui et nous n'avons aucune demande précise @Beginner

Ca me semble plutôt naturel de ne mettre à jour l'onglet qu'au moment où tu en as besoin plutôt que de le mettre à jour à d'autres occasions dans lesquelles l'onglet n'est pas utilisé...

[papajoker]

Si j'ai proposé cette structure, c'est qu'elle tend vers le modèle MVVM. Donc assez simple d'y passer par la suite si le besoin existe (et si techniquement tk n'est pas trop limité ? je connais à peine)
Et, je ne pense pas que Beginner soit encore prêt pour les design patterns. Il cherche surtout une architecture fichiers ; l'indépendance des classes (puisqu'il ne fait pas de tests ?) et autres ne l'intéresse pas encore.

MVVM est classique avec divers gui, par exemple, c'est intégré dans QT mais il nomme les view-model en "model", ce qui porte confusion ; et il n'y a rien pour la liaison viewmodel<->model, et donc souvent le model est intégré par facilité dans le view model par les codeurs.
@Beginner
comprendre l'architecture mvvm c'est en fr et le titre correspond très bien au contenu. (mais pas python)
video "en" mais surtout à voir deux minutes pour les graphiques qui définissent très bien les rôles de ces 3 modules.

Ca me semble plutôt naturel de ne mettre à jour l'onglet qu'au moment où tu en as besoin plutôt que de le mettre à jour à d'autres occasions dans lesquelles l'onglet n'est pas utilisé...

C'est ce que j'avais fait dans l'exemple "simple"
Puisque je n'ai aucune idée du type de l'application... Peut-être qu'il existe 36 onglets juste pour éviter un trop grand formulaire avec scrolling ? peut-être qu'il n'a pas compris qu'utiliser 36 onglets n'empêche pas d'avoir qu'un seul "formulaire" ?

Parfois, nous devons découper notre formulaire (avec bouton suivant) et à cette étape intermédiaire, il peut avoir des controles ( voir sauvegardes). Ok ce ne sont pas des onglets.
Parfois, en fonction d'une saisie dans l'onglet 1, il faut mettre à jour le formulaire de l'onglet 2 ? (si "personne" alors, dans onglet 2, le combo est "parler/chanter"). Note: je pense plus à un mauvais design.
Parfois, en fonction d'un changement dans le formulaire, on peut désirer un changement dans le menu, barre de status, avancement d'une jauge.
Et si le calcul final est long, pourquoi pas avec un bouton "mettre à jour" dans chaque onglet, faire un sous-calcul en cache/parallèle.
Parfois, on a un fichier ".conf" par onglet, il est donc normal de les actualiser dans l'onglet.

[wiztricks]

Si j'ai proposé cette structure, c'est qu'elle tend vers le modèle MVVM. Donc assez simple d'y passer par la suite si le besoin existe (et si techniquement tk n'est pas trop limité ? je connais à peine)

Tk a ses limites mais pas sur ces sujets.

Et, je ne pense pas que Beginner soit encore prêt pour les design patterns. Il cherche surtout une architecture fichiers ; l'indépendance des classes (puisqu'il ne fait pas de tests ?) et autres ne l'intéresse pas encore.

Qu'il soit prêt ou pas, il a demandé comment nous faisions et... il est difficile de s'en passer lorsqu'on connaît ces abstractions.

- W

[Beginner.]

Salut à tous,

Désolé pour le retard et merci pour vos réponses...

Un exemple...

Merci pour cet exemple, je l'ai testé et effectivement on voit par exemple le champ "nom" qui est mis automatiquement à jour, on voit aussi comment l'onglet "Résultat" à accès à tous les champs des deux premiers onglets...

Et effectivement pour faire ce genre de chose il y a les "variables tkinter"...

Petite subtilité (j'en ai parlé mais je le redis): sous Qt tu as la méthode "showEvent()" automatiquement appelée quand un widget (donc un onglet) s'affiche.
Donc l'onglet 2 tu ne le mets pas à jour quand l'onglet 1 fait sa saisie (faisable mais trop casse c... surtout s'il faut le faire sur 10 onglets) mais quand il est affiché. Et là ce n'est pas pareil.
Donc quand un onglet X s'affiche il va chercher les données enregistrées par les autres onglets.

Ok c'est noté. Il me semble que c'est différent dans le code de papajoker, on a par exemple le "nom" que l'on peut modifier à partir du champ présent dans le premier onglet et celui présent dans le deuxième. Si on modifie le nom à partir d'un de ces champs l'autre est mis à jour automatiquement et ce, je pense, même si on n'affiche pas l'onglet en question...

La manière dont tu as développé classA, B et C et ABC ne correspondent pas à un pattern Observer.

Oui tout-à-fait, je ne cherchais pas à utiliser le pattern Observer... Mais cette solution qui permet la communication entre class m'a bien dépannée...

Pour modéliser un peu,

1. Tes onglets seront chacun composés d'un observateur (on pourrait même dire que chacun de tes onglets est un observateur). Perso je préfère la composition...
2. Ton interface composée de tes onglets sera également composée d'un notificateur (gestionnaire des observateurs).
3. L'observateur envoi des messages, signaux, ... lors de la mise à jour ou d'un mouvement quelconque de tes onglets (à mon sens, la création d'un observateur pourrait prendre comme paramètre un callback).
4. Le notificateur va notifier l'interface (application) en envoyant tous les messages, signaux, ... écoutés par tes observateurs.

Merci pour ce modèle, j'y reviendrai je pense quand j'aborderais cette question pattern Observer qui me fait penser aux custom events en js...

1. Qu'est-ce qui justifie la création d'une classe par onglet ? (Y a-t-il tellement d'actions liées à un onglet ?)

Ben en fait au début je n’utilisais pas forcément des class mais j'ai trouvé que l'usage des class était plus pratique pour organiser le code mais aussi pour éviter trop de variables globales.

Quels sont les signaux que peuvent bien envoyer un onglet ? (Si peu de complexité dans les messages, signaux, est-ce que ça nécessite un pattern Oberver ?)

Non effectivement je ne dirais pas qu'un pattern Oberver soit indispensable, la preuve mon programme fonctionne plutôt bien avec la solution que j'ai présentée au message #14... Et apparemment le principe du passage d'instance en argument est utilisé me semble-t-il dans matplotlib...

Bonjour,

...Avec Kivy, le pattern observer se fait avec classe EventDispatcher .
Perso, je ne l'utilise pas et n'en ai jamais encore éprouvé le besoin . De plus, j'us lu un avis qui mentionnait que l'usage pouvait rendre difficile à détecter et à suivre un bug ...
Est ce vraiment de bonne pratique?

Ah ben ça ne m'étonnerait pas que cela ressemble aux custom events en js... Après j'ai quand même l'impression qu'il y a quelques différences avec le pattern Oberver...

@Beginner
comprendre l'architecture mvvm c'est en fr et le titre correspond très bien au contenu. (mais pas python)
video "en" mais surtout à voir deux minutes pour les graphiques qui définissent très bien les rôles de ces 3 modules.

Merci pour ces liens.

[Sve@r]

Il me semble que c'est différent dans le code de papajoker, on a par exemple le "nom" que l'on peut modifier à partir du champ présent dans le premier onglet et celui présent dans le deuxième.

Oui pourquoi pas. Tout est possible selon ton besoin. Un onglet affichant nom et prénom et un autre nom et adresse. Et la modif de l'un ou de l'autre est répercutée en bdd.

Si on modifie le nom à partir d'un de ces champs l'autre est mis à jour automatiquement et ce, je pense, même si on n'affiche pas l'onglet en question...

Là je suis plus mitigé. Comment le prouver ? En affichant l'onglet ? Comme pour la lumière du frigo quand on ouvre la porte pour regarder si la lumière s'éteint...
Mais surtout quel but ? Si l'onglet se met à jour à l'affichage quelque part ça devrait suffire non ?

[Beginner.]

Mais surtout quel but ? Si l'onglet se met à jour à l'affichage quelque part ça devrait suffire non ?

C'était juste pour noter la différence, un simple constat, et non un but à atteindre...

Ceci dit cela pourrait avoir un intérêt dans un autre contexte...

Là je suis plus mitigé. Comment le prouver ? En affichant l'onglet ? Comme pour la lumière du frigo quand on ouvre la porte pour regarder si la lumière s'éteint...

Je pense qu'on pourrait le prouver en lisant le champ en question sans afficher l'onglet... Il me semble que c'est la variable tkinter qui met à jour le champ et non le fait d'afficher l'onglet...