[Thread] Signal/Slot et Thread

Version imprimable

Voir 40 message(s) de cette discussion en une page

14/05/2008, 13h51
yan

Citation:

Envoyé par ttone

:lol:
Je voulais dire, est ce que je peux faire de ma classe "GUI", celle qui implèmente l'interface graphique, une QThread, et éviter de passer ainsi par une autre classe QThread...

J'ai lu que c'était peu souhaitable.

tu peut mais je ne trouve pas ca trés objet et trés propre. QThread n'est pas une clas GUI et faire un héritage multiple avecun QThread et un QWidget.... bof bof bof
Pourquoi vouloir faire ca?
14/05/2008, 13h56
ttone

Citation:

je ne trouve pas ca trés objet et trés propre

c'est clair, j'essaie de trouver une bonne approche, pour clarifier un peu la mise en place des mutexs si besoin est.

Et surtout pour minimaliser et trouver mon erreur.

Enfin bref, du coup au lieu de créer une QThread "Media", j'ai tout passé dans ma classe principale. Ca évite les public, etc.
Je gagne en nombre de méthode, variable qui se répétait, etc...
et ca ne change pas grand chose en conception.
Disons que la gestion media passe dans la GUI même.
Et pour celle là paradoxalement je n'ai pas besoin de QThread.

Je mets en place la QThread uniquement pour le timer.

Et je verrai ce que ca donne.

Ca va se résumer à un run qui contient un emit.
Ca devrait finir par fonctionner... :triste:
14/05/2008, 13h57
ttone

Citation:

faire un héritage multiple avecun QThread et un QWidget

:nono:
En effet, j'oublie tout de suite l'idée.
14/05/2008, 14h00
yan

Citation:

Envoyé par ttone

c'est clair, j'essaie de trouver une bonne approche, pour clarifier un peu la mise en place des mutexs si besoin est.

Et surtout pour minimaliser et trouver mon erreur.

Enfin bref, du coup au lieu de créer une QThread "Media", j'ai tout passé dans ma classe principale. Ca évite les public, etc.
Je mets en place la QThread uniquement pour le timer.

Et je verrai ce que ca donne.

Ca va se résumer à un run qui contient un emit.
Ca devrait finir par fonctionner... :triste:

Je suis perdu...
Peut tu me redire ce que doit faire ton thread??
Quel est ton erreur?
14/05/2008, 14h01
IrmatDen

Non, tu ne peux pas mettre la GUI dans un autre thread. Et tout mettre dans la classe principale, c'est plus que déconseillé. Se retrouver avec une grosse classe monolithique sans le moindre rôle exact est une horreur à retoucher (je l'ai fait aussi par le passé et je te recommande vivement de réfléchir à une conception plus propre du style 1 classe <=> 1 responsabilité).
14/05/2008, 14h04
Alp

La conception "type" dans ce genre de situation est comme l'a dit IrmatDen de confier à une classe une responsabilité.

Plus tu divises en morceaux la fonction principale de ton programme, plus facile ce sera de rajouter des fonctionnalités, modifier ce qui existe, etc...
Ici, tu dois séparer tout ce qui concerne ton thread du GUI, et les relier grâce au fabuleux système de signal-slot de Qt. Ils ne doivent rien partager d'autre.
14/05/2008, 14h16
yan
Code:

1 2 3 4 5 6 7 8 void SoundSystem::run() { this->play(5000); emit renderPosition(7); }
????
ou est la boucle ????????
quand tu fera start, un thread sera créé, puis ces deux ligne seront appélé puis ta thread sera fini!!!!!

faut au moins une boucle
Code:

1 2 3 4 5 6 7 void SoundSystem::run() { while(aze) { ... } }
Et si tu veut utiliser l'eventloop tu doit la lancer
Code:

1 2 3 4 5 6 void SoundSystem::run() { ... exec(); }
14/05/2008, 14h20
ttone

Citation:

????
ou est la boucle ????????
quand tu fera start, un thread sera créé, puis ces deux ligne seront appélé puis ta thread sera fini!!!!!

Attends, avec ou sans boucle meme résultat : que dalle.
La loop est prévu au programme final...

Citation:

Et si tu veut utiliser l'eventloop tu doit la lancer

C'est quoi concrètement la différence entre eventloop et thread lancé par le run ? Le run lance un thread qui lance une eventloop qui effectue le contenu du run ?
14/05/2008, 14h21
ttone

Citation:

La conception "type" dans ce genre de situation est comme l'a dit IrmatDen de confier à une classe une responsabilité.

C'est sûr.
14/05/2008, 14h28
IrmatDen

Citation:

Envoyé par ttone

Attends, avec ou sans boucle meme résultat : que dalle.
La loop est prévu au programme final...

C'est quoi concrètement la différence entre eventloop et thread lancé par le run ? Le run lance un thread qui lance une eventloop qui effectue le contenu du run ?

Je ne comprends pas pourquoi vous vous échiner à vouloir mettre une boucle d'événement dans le thread? Quels événements de Qt as-tu à gérer dans le thread? J'ai cru comprendre que c'était un thread pour utiliser FModEx et émettre des infos. C'est tout ou y'a autre chose?

(Note: je n'étais pas là pdt quelques jours, et je suis arrivé avec déjà 3 pages de posts, donc j'ai peut-être raté quelque chose)
14/05/2008, 14h29
ttone

Ok, bon résultat, je reviens à mon truc, une GUI, un Sound System, qui contient un run magnifique,

dans ce run un while, et dans ce while un emit, et dans cet emit une variable, fixée à const int 10 pour les besoins du test

Le emit ne fait pas frétiller le SLOT de la GUI d'un poil

et d'ailleurs, aux derniers tests, c'est le SLOT qui est mauvais...

Pourtant, ... il est bien déclaré dans les private slots,
il prend bien les mêmes arguments.
Il est même du même type.

:aie::aie::aie::marteau:

Y a t il une différence de déclaration notable pour les CONNECT, entre un signal émis depuis une QThread et un signal émi depuis son THREAD ?

:?:
14/05/2008, 14h38
IrmatDen

Peux-tu coller ici la déclaration + implémentation du thread, la déclaration de la classe contenant le slot, son implé, ainsi que la fonction/classe où le connect est fait?
Ton archive faisant 8MB avec un débit de 50kB, ce sera plus pratique de n'avoir que l'essentiel ;)

Pour ta question, c'est pas vraiment clair. As-tu lu ceci: Signals and Slots Across Threads ?

Citation:

Pour ta question, c'est pas vraiment clair. As-tu lu ceci: Signals and Slots Across Threads ?

Oui je l'ai lu, je suis en queued connection, et dans le même cas de figure que l'exemple Mandelbrot.

Citation:

Peux-tu coller ici la déclaration + implémentation du thread,

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
#ifndef SOUNDSYSTEM_H
#define SOUNDSYSTEM_H
 
#include <QMutex>
#include <QSize>
#include <QThread>
#include <QWaitCondition>
 
class SoundSystem : public QThread
 {
     Q_OBJECT
 
public:
    SoundSystem(QObject *parent = 0);
	~SoundSystem();
protected:
void run();
 
private:
bool timecount;
 
signals:
   	void renderPosition(unsigned int position);
 };
#endif

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include "SoundSystem.h"
#include <QtGui>
#include <fstream>
#include <iostream>
#include <QKeyEvent>
 
using namespace std;
 
SoundSystem::SoundSystem(QObject *parent)
: QThread(parent)
{
	timecount=true;
};
 
SoundSystem::~SoundSystem(){
 
};
 
void SoundSystem::run()
{
 
	while(timecount){
		emit renderPosition(7);
		sleep(1);
	}
 
 
}

Citation:

la déclaration de la classe contenant le slot

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include "ui_GUI.h"
#include "SoundSystem.h"
 
using namespace std;
 
class GUI : public QMainWindow
{
Q_OBJECT
 
public:
    GUI(QWidget *parent = 0);
	~GUI();
 
private slots:
	void rPosition(unsigned int position);
 
private:
        Ui_GUI interface;
	SoundSystem *audioThread;
 
signals:
	void renderPosition(unsigned int position);
};

Citation:

son implé

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include "GUI.h"
#include <stdio.h>
#include <QtGui>
#include <QtCore>
#include <time.h>
#include <string>
#include <fstream>
#include <iostream>
 
using namespace std;
 
GUI::GUI(QWidget *parent)
: QMainWindow(parent)
{
	this->interface.setupUi(this);
	audioThread = new SoundSystem(this);
	Connect(audioThread, SIGNAL(renderPosition(unsigned int position)), this, SLOT(rPosition(unsigned int position)));
 
};
 
 
GUI::~GUI(){
};
 
void GUI::rPosition(unsigned int position){	
	this->interface.transportSlider->setValue(77);
	this->interface.timeLabel->setText(QString("544"));
};

Citation:

, , ainsi que la fonction/classe où le connect est fait?

Code:

1
2
3
4
void GUI::rPosition(unsigned int position){	
	this->interface.transportSlider->setValue(77);
	this->interface.timeLabel->setText(QString("544"));
};

14/05/2008, 15h18
IrmatDen

Ah, ben voilou :)

Code:

Connect(audioThread, SIGNAL(renderPosition(unsigned int position)), this, SLOT(rPosition(unsigned int position)));

1. connect s'écrit en minuscule
2. les signaux/slots ne doivent comporter que les signatures, pas les noms de paramètres

Et pour finir, tu ne démarres pas ton thread dans le snippet posté (à vérifier avec le reste de ton code bien sûr)

PS: pas besoin de ; après l'implémentation des fonctions (ça ne fait rien de mal, mais c'est inutile)
14/05/2008, 15h21
ttone
Citation:

connect s'écrit en minuscule

erreur de frappe ici, c est en minuscule dans mon prog,
j'ai donc passé :
Code:

1 2 connect(audioThread, SIGNAL(renderPosition(unsigned int)), this, SLOT(rPosition(unsigned int)));
et ca marche... :wow:

Citation:

PS: pas besoin de ; après l'implémentation des fonctions (ça ne fait rien de mal, mais c'est inutile)

c'est psychologique, quand je commence à tourner en rond, je met du verni "le point virgule"...

merci
14/05/2008, 15h24
yan

Citation:

Envoyé par IrmatDen

Je ne comprends pas pourquoi vous vous échiner à vouloir mettre une boucle d'événement dans le thread?

Ce n'etait pas une volonté. J'ai essayer de lui expliquer deux façon d'utiliser les thread avec Qt pour lui permettre de choisir celle qui lui correspond.
Puis au bout d'un moment on mélange tout :cry: maintenant avec son code c'est plus claire;)

Donc au final tu va y faire quoi dans le run??
14/05/2008, 15h31
ttone

donc au final... j'y lance la lecture, et le compteur.

en fait je vais devoir créer une QThread pour le compteur, instanciée dans la QThread pour la lecture, instanciée dans la GUI

Un truc bizarre pour le son, avec FMODex, ses méthodes ne sont plus asynchrones, une fois "play" lancée, la bande son est jouée... et on peut intervenir sur les canaux, le volume et tout.
DANS LE MAIN THREAD

Là j'ai calé "play", puis mon compteur, dans le run : le compteur marche mais play est zappé. Comme si il était asynchrone.

Bref, je vais faire 2 threads.

Le probleme que j'ai d'emblée, c'est le besoin de passer à mon run des variables venant de la classe d'audessus... puisque je vais dire à mon compteur : récupère la position de la tête de lecture à chaque pas...
Hors la tête de lecture, elle est gérée par ma QThread qui "start" le compteur
14/05/2008, 15h33
IrmatDen
Citation:
Envoyé par ttone

erreur de frappe ici, c est en minuscule dans mon prog,
j'ai donc passé :

Code:

1 2 connect(audioThread, SIGNAL(renderPosition(unsigned int)), this, SLOT(rPosition(unsigned int)));

et ca marche... :wow:
C'est pour ça qu'en phase de debug, j'insiste et rappel et insiste encore pour que tout le monde utilise le mode console. Si tu utilises les fichiers pro, c'est tout simple:
Code:

1 2 3 CONFIG(debug, debug|release) { CONFIG += console }
14/05/2008, 15h34
ttone

j'add de suite, j'avais ca dans mon .pro

Code:

CONFIG += console
14/05/2008, 15h34
Alp

Pour cela, crée une classe qui hérite de QThread avec comme paramètres au constructeur les paramètres dont tu parles.

Ensuite, tu n'as qu'à stocker une instance de cette classe dans ta classe de fenêtre principale, et connecter le run du thread au signal que tu veux (appui sur play, ...). Et dans le constructeur de ta classe fenêtre principale, ou dans une autre méthode, tu construis ton instance de thread dérivé en donnant les paramètres que tu désires au constructeur.
14/05/2008, 15h35
ttone

exact, merci ;)
14/05/2008, 16h36
yan

Citation:

Envoyé par ttone

Le probleme que j'ai d'emblée, c'est le besoin de passer à mon run des variables venant de la classe d'audessus... puisque je vais dire à mon compteur : récupère la position de la tête de lecture à chaque pas...
Hors la tête de lecture, elle est gérée par ma QThread qui "start" le compteur

Il est donc préférable d'utiliser un mutex
14/05/2008, 17h44
yan

En y réfléchissant...
pourquoi veut tu utiliser une thread???
14/05/2008, 20h02
ttone

pour pas que l compteur freeze mon appli.
J'ai vérifié, il la freeze bien.
Je n'ai plus accès à la GUI en éxcécution.
14/05/2008, 20h18
yan

Citation:

Envoyé par ttone

pour pas que l compteur freeze mon appli.
J'ai vérifié, il la freeze bien.
Je n'ai plus accès à la GUI en éxcécution.

:koi:
as tu essayé un QTimer qui à temps régulier va regardé la position de lecture?
http://qt.developpez.com/doc/latest/qtimer.html#details
14/05/2008, 21h34
yan

1 pièce(s) jointe(s)

voici un exemple d'utilisation d'un QTimer.
En je voulais m'en servir pour te faire un exemple avec QThread et c'est la ou je ne comprenais plus pourquoi tu avait besoin d'un thread...

Ici tu as un objet qui à temp régulier va émettre une position et une QImage. Une IHM affichera tout cela.
Dsl j'ai pas eu le courage de faire des commentaire.
Mais si tu as des question pas de problème.

Pour ton problème, en gros tu va regarder la position de lecture à temps régulier
[edit]
nouveau code car oublié de mettre un fond avec painter :aie:
[/edit]
15/05/2008, 01h02
ttone

merci mec, je regarderai ca demain (tiens on est déja demain lol...)

décidemment Qt en tous cas.

PS : d'ailleurs avec mon thread-compteur, ca freezait si je ne faisais pas un petit sleep(1), c'est pour lui laisser le temps de repasser la main ou c'est juste anormal ?
15/05/2008, 14h31
ttone

Parfait, le QTimer marche parfaitement.
15/05/2008, 15h28
ttone

Le seul truc c'est que mon QTimer active le slot de positionnement de la tete de lecture, et qu'a la main via la GUI on peut bouger soi meme la tete de lecture pour se déplacer à différents points du track.

Résultat : si la fréquence du timer est trop forte, il empeche de bouger a la main la tete de lecture.

Ca ne freeze pas, donc pas besoin de thread, mais du coup j'ai fixé une pulse de 1sec pour le timer, en dessous ca n'est pas gérable.

Je pourrai également affiner la tete de lecture en changeant la résolution du slider via QtDesigner, et profiter d'une pulse de 10ms, graphiquement ce serait plus fluide et plus esthétique, mais je serais bloqué pour l'exploration.
15/05/2008, 15h32
yan

Citation:

Envoyé par ttone

Résultat : si la fréquence du timer est trop forte, il empêche de bouger à la main la tête de lecture.

pourquoi?
15/05/2008, 15h56
ttone

En fait il empeche pas, mais il l'acquisition ne se fait pas forcément...

Je vois si c'est pas une question de bon choix du SIGNAL sur le slider...
15/05/2008, 17h03
ttone

Citation:

Citation:
Envoyé par ttone Voir le message
Résultat : si la fréquence du timer est trop forte, il empêche de bouger à la main la tête de lecture.
pourquoi?

En fait c'est tout bête, le timer repositionne la tete de lecture toutes les X ms,

si je le pulse à 10 ms, je n'ai pas le temps de déplacer la tete que le timer s'est déjà chargé de l'actualiser...
15/05/2008, 17h05
ttone

ce que je vais faire:
* placer ce timer dans un thread->run()
* jouer du mutex
15/05/2008, 17h13
yan

Citation:

Envoyé par ttone

En fait c'est tout bête, le timer repositionne la tete de lecture toutes les X ms,

si je le pulse à 10 ms, je n'ai pas le temps de déplacer la tete que le timer s'est déjà chargé de l'actualiser...

??
je ne connait pas trop fmod mais je ne voie pourquoi c'est toi qui doit déplacer la tête de lecture....
Normalement fmod le fait tous seul aprés avoir lancé la lecture. Toi tu doit regarder juste la position de la tête à temps régulier.... non??

voici un autre exemple avec un QObject qui possède une valeur qui avance(peut representer la lecture d'un fichier) et une interaction avec un slider

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
#include <QtGui>
 
class myPosition:public QObject
{
Q_OBJECT
public:
    myPosition():QObject(),m_position(0)
    {
        connect(&m_timer,SIGNAL(timeout()),this,SLOT(avancer()));
        m_timer.start(100);
    }
    QTimer m_timer;
    int m_position;
 
 
signals :
    void position(int);
 
public slots:
    void setPosition(int pos)
    {
        m_position = pos ;
    }
    void pause()
    {
        m_timer.stop();
    }
    void play()
    {
        m_timer.start(100);
    }
 
    void avancer()
    {
        m_position++;
        if (m_position>100 )  m_position =100;
        emit position(m_position);
    }
};
#include "main.moc"
 
 
int main(int argc,char ** argv)
{
QApplication app(argc,argv);
QSlider slider;
myPosition position;
    QObject::connect(&slider,SIGNAL(sliderPressed ()),&position,SLOT(pause()));
        QObject::connect(&slider,SIGNAL(sliderMoved (int)),&position,SLOT(setPosition(int)));
    QObject::connect(&slider,SIGNAL(sliderReleased  ()),&position,SLOT(play()));
    QObject::connect(&position,SIGNAL(position(int)),&slider,SLOT(setValue(int)));
slider.show();
return app.exec();
}

15/05/2008, 17h34
ttone

Citation:

Fichiers attachés
Type de fichier : rar testTHread.rar (1,5 Ko, 3 affichages)

Cool ce code, je suis en train de le regarder, apparemment dans celui ci déjà tu n'as pas de probleme d'interaction avec le slider...
15/05/2008, 17h42
yan

Citation:

Envoyé par ttone

Cool ce code, je suis en train de le regarder, apparemment dans celui ci déjà tu n'as pas de probleme d'interaction avec le slider...

Tout dépend de l'interaction que tu veut.
Le dernier code que j'ai mie est un peu meilleur car le slider envoie un signal que lorsque tu le bouge avec la souris et l'avancement est stoppé pendant le drag
15/05/2008, 17h55
ttone

Citation:

l'avancement est stoppé pendant le drag

c'est ca que je dois mettre en place.
Sinon je dois faire un mauvais truc en mettant une pulse lente au QTimer.

Citation:

le slider envoie un signal que lorsque tu le bouge avec la souris

Dans mon cas, ca c'est inhérent. Je ne récupère le signal que si l'utilisateur a "released" le slider... le probleme c'est qu'il n'a pas le temps de le relacher que deja le slider s'est repositionné.

J'ai testté d'autres signaux dérivant de QAbstractbutton notamment, comme clicked, mais ca ne marche pas bien, voir pas du tout, bien que la doc Trolltech les mentionne pour un QSlider.
15/05/2008, 18h02
yan

sert toi du dernier code alors ;)
15/05/2008, 18h09
ttone

c'est sliderMoved qui freeze automatiquement les autres signaux ?

Voir 40 message(s) de cette discussion en une page