Discussion :

[LittleWhite]

Bonjour à tous,

Cette fois, je me pose la question sur la gestion d'une boite de paramètre d'une application.

Actuellement, lorsque je dis boite de paramètre, c'est un QDialog que j'appelle par l'intermédiaire d'un menu, et qui permet de changer quelques variables, qui sont généralement global aux programmes.

Je crois qu'il y a un QSettings, il faudrait que je me penche la dessus, mais si vous pouviez m'en dire quelques mots, et si cela convient bien à mon besoin, j'en serai enchanté. ( Sinon je peux lire la documentation vous allez me dire )

Revenons un peu mon problème ( que je n'ai toujours pas présenté ). Actuellement ma question est, comment faire pour envoyer les nouvelles valeurs des paramètres aux éléments de l'application qui en ont besoin.

Je ne suis pas sans solution:

- Des variables globales ( c'est toujours déconseillé )
- Un singleton qui permet de contenir les données ( c'est très très moyen ( dans le sens, mauvais ) )
- Des getteurs ( accesseurs ) sur la classe qui gère la boite de dialogue pour les préférences ( ça commence à être bien, mais la boite de dialogue à une durée de vie limitée, donc cela est finalement peut être dur à géré )
- Des signaux ( Je trouve ça une bonne idée )
- Obiwan Kenobi et Chuck Norris suffiront

Pour l'instant j'aime bien l'idée des signaux ( je peux changer du jour au lendemain ).
Mais comme la boite de dialogue est crée dans un slot de la fenêtre principale.
Le code donne ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
void monSlot(void)
{
  MyDialog dialog();
  dialog.exec();
  // Destruction immédiate
}

Avec des signaux cela sera du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
void monSlot(void)
{
  MyDialog dialog();
 
  connect(dialog, SIGNAL(newSetting()), element_that_need_it, SLOT(changedValue)));
 
  dialog.exec();
 
  disconnect(dialog); // C'est très schématique
  // Destruction immédiate
}

Donc, on voit que je m'intéresse à la déconnexion des signaux, vu que ma boite va mourir juste après ( et aussi, parce que si l'utilisateur rappel la boite, on va refaire les mêmes signaux, et un jour je vais avoir des problèmes ).

Qu'est ce que vous en pensez?
La solution des signaux est elle la meilleure? Est ce que mon implémentation est correcte, ou j'oublie un point important?

Merci pour votre aide.

[yan]

Qu'est ce que vous en pensez?

Que si tu utilise Chuck Norris c'est pas toi qui va choisir les paramètres...

En un lien
http://qt.developpez.com/doc/latest/qdialog.html#exec

[LittleWhite]

Bien sur, dans mon code, à la place de show() c'est des exec() de ma boite de dialogue. Là dessus pas de problèmes. ( Enfin je crois pas ).

Ma boite tourne bien, je peux jouer avec, mes je voudrais savoir comment je répercute les valeurs que j'aurai défini dans ma boite, dans le reste du programme.

Chuck Norris il n'a pas besoin de boite de dialogue, il peut remodeler le monde juste avec ses mains

[yan]

Quand tu ferme ta dialog, le programme sort du exe et continue.
Il te suffit de récupérer les valeurs juste après le exec().

ps: pas besoin de faire disconnect, c'est automatique avec les destruction du QObject

[LittleWhite]

Quand tu ferme ta dialog, le programme sort du exe et continue.
Il te suffit de récupérer les valeurs juste après le exec().

ps: pas besoin de faire disconnect, c'est automatique avec les destruction du QObject

Donc ce que vous me conseillez, c'est d'utiliser des accesseurs sur ma classe de boite de dialogue afin de récupéré les valeurs des paramètres?

Question: Est ce que si on peut évité d'utiliser les signaux dans Qt, faut t'il le faire? ( Par exemple, ici, j'ai le choix entre signaux et accesseurs, le plus optimisé va certainement être, les accesseurs.

[yan]

Question: Est ce que si on peut évité d'utiliser les signaux dans Qt, faut t'il le faire? ( Par exemple, ici, j'ai le choix entre signaux et accesseurs, le plus optimisé va certainement être, les accesseurs.

Ca dépend ce que tu veux faire.

Si ton affichage doit changer en "temps réelle" alors tu as besoin de signaux.
Sinon, ben ca depend de ton besoin.

Perso, entre faire 20 signaux ou un simple accésseur sur une struct (ou que des membre public) contenant toutes les valeurs entrées, mon choix est simple

Niveau optimization, tu ne verra pas de différence avec l'une ou l'autre.

[LittleWhite]

D'accord

Merci pour vos indications

[ymoreau]

QSettings est vraiment super pratique, tu devrais l'utiliser, surtout que c'est très simple à faire. En créant un objet n'importe où dans ton programme tu as accès à toutes les variables de config que tu auras affecté. En pratique c'est aussi simple à utiliser qu'un singleton donc, mais en plus tu ne gères pas la classe singleton.

Et pour la question de comment gérer les variables de config (sans QSettings), le singleton me semble le mieux. Sinon tu es obligé de faire gérer ses données par une classe centrale non singleton qui doit propager leurs valeurs à chaque modif, je trouve ça super lourd. Alors qu'avec un singleton chaque classe gère elle même ses variables de config (en lecture seule, ou pas).

[LittleWhite]

Oui, le QSettings ( j'ai lu la doc ) semble pas mal.

Mais cela ne résout pas mon problème ( enfin pas la question que j'avais posé ). Il faut toujours prévenir l'objet qu'il y a du changement. Donc on en revient au même point de départ.

Sinon, je vais quand même intégré le QSettings juste pour m'amuser un peu ( c'est totalement implémenter comme je l'aurai imaginé \o/ )

[yan]

Il faut toujours prévenir l'objet qu'il y a du changement.

C'est à dire? tu cherche à faire quoi?

[LittleWhite]

Simplement, j'ai une application, avec une fenêtre principale, un QGLWidget, dans cette fenêtre.
La boite de dialogue est appelée par un menu de la fenêtre principale.
La boite de dialogue change la couleur des courbes qui sont dessiner par le QGLWidget.
Le seul lien entre la boite de dialogue, et la QGLWidget, c'est la fenêtre principale.
Le deuxième lien que je pouvais avoir c'est avec des signaux, pour dire que les paramètre ( couleur de courbe ) avait changé.

Sinon, la dernière solution: QSettings, mais il me faut une sorte de listener sur les valeurs des paramètre. Je ne trouve pas cela bien, car je ne veux pas vérifié toute les n secondes si mes valeurs ont changé ou pas.

[yan]

Simplement, j'ai une application, avec une fenêtre principale, un QGLWidget, dans cette fenêtre.
La boite de dialogue est appelée par un menu de la fenêtre principale.
La boite de dialogue change la couleur des courbes qui sont dessiner par le QGLWidget.
Le seul lien entre la boite de dialogue, et la QGLWidget, c'est la fenêtre principale.
Le deuxième lien que je pouvais avoir c'est avec des signaux, pour dire que les paramètre ( couleur de courbe ) avait changé.

Sinon, la dernière solution: QSettings, mais il me faut une sorte de listener sur les valeurs des paramètre. Je ne trouve pas cela bien, car je ne veux pas vérifié toute les n secondes si mes valeurs ont changé ou pas.

Alors les signaux est la bonne méthode.
J'ai du mal à voire ou tu as un problème...

[LittleWhite]

Alors les signaux est la bonne méthode.
J'ai du mal à voire ou tu as un problème...

Vous êtes drole , mais hier, vous m'avez dit, c'est mieux les accesseurs / getteurs, car on n'utilise pas les signaux, et maintenant vous me dites les signaux
Mon problème, j'en ai pas vraiment, je pose des questions de design. Pour savoir comment bien coder avec Qt.
Et je pensais avoir un bon design, depuis que j'ai mis ce sujet en résolu ... mais vous cassez tout ( Yan serait t'il Chuck Norris ? )

[yan]

Vous êtes drole , mais hier, vous m'avez dit, c'est mieux les accesseurs / getteurs, car on n'utilise pas les signaux, et maintenant vous me dites les signaux

tu as lue trop vite.

Si ton affichage doit changer en "temps réelle" alors tu as besoin de signaux.
Sinon, ben ca depend de ton besoin.

ha oui.... ca c'etait pour le deuxième cas

Perso, entre faire 20 signaux ou un simple accésseur sur une struct (ou que des membre public) contenant toutes les valeurs entrées, mon choix est simple

si tu veux une fenêtre qui contient des commandes, et que la modification de ces commandes modifie l'affichage d'une autre fenêtre en même temps, les signaux est une bonne solution. C'est même un peu le but en faite.

[LittleWhite]

si tu veux une fenêtre qui contient des commandes, et que la modification de ces commandes modifie l'affichage d'une autre fenêtre en même temps, les signaux est une bonne solution. C'est même un peu le but en faite.

Entièrement d'accord. Mais je n'ai pas ce besoin ( ou je ne veux pas laisser cette possibilité à l'utilisateur )

[yan]

Mais je n'ai pas ce besoin ( ou je ne veux pas laisser cette possibilité à l'utilisateur )

Alors j'ai pas compris ce que tu voulais savoir...
Si je voulais résumer, j'aurais dit un truc comme :

• QSettting : pour sauvegarder des paramètres entre plusieurs exécution de l'appli
• Signaux : pour que l'ihm réagit au moment de la modification d'un paramètre (je change la couleur d'une courbe dans la dialog, la courbe à changé de couleur en même temps)
• Accésseur,membre public, ou tous ce que tu veux : Pour modifier un ensemble de paramètres et que l'ihm se met à jour une fois fini(fermeture du dialog par exemple ou "valider"). Rien n'empêche que ce soit un signal qui soit emit aprés l'edition des paramètres.

Tous dépend de ce que tu veux faire.

Après tu peut imaginer toutes les variantes possible et imaginable.
D'où l'expression
"trop de signaux tue le programmeur" © yan

[LittleWhite]

Alors j'ai pas compris ce que tu voulais savoir...

Pardon de m'être très mal exprimé.

Au tout début je demandais pour savoir comment faire pour géré ma boite de dialogue, et surtout la communication des paramètres avec le reste de l'application. Mais la question était strictement d'un point de vue design du code. Tout ce qui a était énuméré ici, je sais faire.

Si je voulais résumer, j'aurais dit un truc comme :

• QSettting : pour sauvegarder des paramètres entre plusieurs exécution de l'appli
• Signaux : pour que l'ihm réagit au moment de la modification d'un paramètre (je change la couleur d'une courbe dans la dialog, la courbe à changé de couleur en même temps)
• Accésseur,membre public, ou tous ce que tu veux : Pour modifier un ensemble de paramètres et que l'ihm se met à jour une fois fini(fermeture du dialog par exemple ou "valider"). Rien n'empêche que ce soit un signal qui soit emit aprés l'edition des paramètres.

Entièrement d'accord avec vous

[ymoreau]

Le plus simple me semble :
- ta Dialog permettant de modifier les paramètres, les sauvegarde dans QSettings, émet un (ou plusieurs si tu as plusieurs sous groupes de paramètres) signal disant "les valeurs ont changé"
- ton ou tes widgets ont un slot appliquant les paramètres sur eux mêmes (en les lisant dans QSettings)
- tu connectes les signaux de la Dialog aux slots de mise à jour de tes widgets

[LittleWhite]

Le plus simple me semble :
- ta Dialog permettant de modifier les paramètres, les sauvegarde dans QSettings, émet un (ou plusieurs si tu as plusieurs sous groupes de paramètres) signal disant "les valeurs ont changé"
- ton ou tes widgets ont un slot appliquant les paramètres sur eux mêmes (en les lisant dans QSettings)
- tu connectes les signaux de la Dialog aux slots de mise à jour de tes widgets

C'est effectivement une solution envisageable.

Merci pour toutes vos réponses

[yan]

Le plus simple me semble :
- ta Dialog permettant de modifier les paramètres, les sauvegarde dans QSettings, émet un (ou plusieurs si tu as plusieurs sous groupes de paramètres) signal disant "les valeurs ont changé"
- ton ou tes widgets ont un slot appliquant les paramètres sur eux mêmes (en les lisant dans QSettings)
- tu connectes les signaux de la Dialog aux slots de mise à jour de tes widgets

Personnellement, je ne trouve pas que QSetting est fait pour cela.