Documentation Qtfr - signaux-slots

Interaction entre boost.signals et les signaux/slots Qt

IrmatDen — Wed, 21 May 2008 20:46:00 +0200

Comment faire cohabiter les signaux/slots de Qt avec la librairie boost.signals ?

Ce tutoriel est destiné à vous guider pour mettre en place une interaction entre boost.signals et le mécanisme de signaux/slots Qt.

Version : Qt4
Auteur : Denys Bulant (IrmatDen)
Fil de discussion : Forum

Pré requis:

La connaissance du fonctionnement des signaux/slots avec Qt
Une connaissance basique de boost.signals
Une connaissance basique de boost.functional (tout particulièrement les fonctions de binding)

Introduction

Il est intéressant de savoir faire ceci dans la mesure où vous désireriez utiliser des classes écrites en C++ pur avec les mécanismes Qt. Par exemple, une couche métier utilisant le mécanisme de boost.signals comme implémentation du pattern observateur, que vous désirez connecter à la couche IHM écrite à l'aide de Qt.
Toutefois, cet article n'est ni une introduction à Qt, ni à boost.signals.

Précautions et conflits

Premièrement, il y a un conflit entre boost et Qt au niveau du terme "signals". En effet, Qt déclare celui-ci comme #define signals protected, tandis qu'il s'agit d'un type boost. Il y a plusieurs façons de résoudre ce conflit:

Inclure les en-têtes boost en premier
Placer boost.signals dans son propre namespace (pour plus d'infos se référer à la Q/R 3 de la FAQ boost.signals)
Depuis Qt 4.1, Trolltech à ajouté le paramètre no_keywords à la liste des valeurs potentielles pour CONFIG. Ajouter CONFIG += no_keywords dans votre fichier pro vous permettra donc d'utiliser sans soucis boost.signal. Le bémol de cette solution est que les "mots clés" suivant disparaissent au profit des macros suivantes:

signals -> Q_SIGNALS
slots -> Q_SLOTS
emit -> Q_EMIT
foreach -> Q_FOREACH
forever -> Q_FOREVER

Les slots de Qt sont des méthodes standard, qui ont en plus la possibilité de connaître son émetteur (à la condition sine qua non que son appel soit lié à l'émission d'un signal). L'usage de cette fonction est grandement déconseillé en temps normal (QSignalMapper devrait amplement suffir pour s'en passer). Mais dans certains rares cas, vous pouvez avoir absolument besoin de cette info : dans ce cas pensez bien à vérifier que le QObject* retourné n'est pas null. Dans ce dernier cas, c'est que le slot a été invoqué de façon normale (c'est ce que l'on fait en connectant un slot Qt à un signal boost).

Interaction boost.signals et signaux/slots Qt

Je vais maintenant aborder 3 interactions possibles entre ces 2 bibliothèques:

Utilisation d'un boost.signal connecté à un slot Qt
Utilisation d'un boost.signal connecté à un signal Qt
Utilisation d'un signal Qt connecté à une (ou des) fonction(s) C++ standard par le biais de boost.signals

Vous trouverez un code d'exemple reprenant ces 3 aspect en pièce jointe de ce document. Dans ce code, n'oubliez pas de régler les valeurs de LIBS et INCLUDEPATH de manière à correspondre à votre configuration.

Utilisation d'un boost.signal connecté à un slot Qt

Un slot au sens Qt est en réalité une fonction standard. Par conséquent, il est trivial d'en connecter un à un signal boost.
La seule chose différente entre un slot et une méthode de classe standard est la possibilité de récupérer des infos sur l'objet appelant (par le biais de QObject::sender()). Je tiens à souligner à nouveau le "danger" posé par cette méthode: si le slot n'est pas appelé par un signal, le QObject* renvoyé sera null. Par conséquent, réduisez au minimum son utilisation, et vérifiez toujours la validité de l'objet renvoyé!

class QtClass : public QObject
{
Q_OBJECT
public slots:
    void qtSlot(float x)
    {
        QObject *s = sender();
        if(s == this)
            std::cout << "From internal connection:" << std::endl;
        else if(!s)
            std::cout << "Unknown sender:" << std::endl;
        std::cout << "In QtClass::qtSlot(), x=" << x << std::endl;
    }
};
 
class NonQtClass
{
public:
    void boostSignalToQtSlot(QtClass *qc)
    {
        boost::signal<void (float)> sig;
        sig.connect(boost::bind(&QtClass::qtSlot, qc, _1));
        sig(3.14f);
    }
}; 
 
int main(int argc, char **argv)
{
    NonQtClass nqc;
    QtClass    qc;
 
    // Déclenche un boost::signal attaché à un slot Qt:
    nqc.boostSignalToQtSlot(&qc);
 
    return 0;
}

Sortie obtenue:

Unknown sender:
In QtClass::qtSlot(), x=3.14

Utilisation d'un boost.signal connecté à un signal Qt

Un signal au sens Qt n'est qu'une méthode standard, le mot clé signals étant redéfini par Qt comme protected. Il est donc nécessaire de fournir une méthode permettant de déclencher ce signal avec le(s) paramètre(s) voulu(s). Il y a 2 approches possible; la première consiste à ajouter une méthode à votre classe Qt, la seconde à utiliser une classe de pont.
Bien que plus verbeuse, la seconde méthode permet de découpler réellement la couche utilisant Qt de la couche sans Qt en "intercalant" une couche servant d'aptateur. Ici, ce sera la première méthode qui sera illustrée; la seconde le sera dans le 3ème et dernier point.

class QtClass : public QObject
{
Q_OBJECT
 
public:
    QtClass()
    {
        connect(this, SIGNAL(qtSignal(float)), this, SLOT(qtSlot(float)));
    }
 
    // OBLIGATOIRE si on veut connecter un signal boost à un signal Qt: les signaux sont **protégés**
    void triggerQtSignalEmission(float x)
    {
        emit qtSignal(x);
    }
 
public slots:
    void qtSlot(float x)
    {
        QObject *s = sender();
        if(s == this)
            std::cout << "From internal connection:" << std::endl;
        else if(!s)
            std::cout << "Unknown sender:" << std::endl;
        std::cout << "In QtClass::qtSlot(), x=" << x << std::endl;
    }
 
signals:
    void qtSignal(float);
};
 
class NonQtClass
{
public:
    void boostSignalToQtSignal(QtClass *qc)
    {
        boost::signal<void (float)> sig;
        sig.connect(boost::bind(&QtClass::triggerQtSignalEmission, qc, _1));
        sig(42.0f);
    }
};
 
int main(int argc, char **argv)
{
    NonQtClass nqc;
    QtClass    qc;
 
    /* Déclenche un boost::signal lié à l'émission d'un signal Qt
       (on triche par l'utilisation d'une méthode intermédiaire obligatoire) */
    nqc.boostSignalToQtSignal(&qc);
 
    return 0;
}

Sortie obtenue:

From internal connection:
In QtClass::qtSlot(), x=42

Utilisation d'un signal Qt connecté à une (ou des) fonction(s) C++ standard par le biais de boost.signals

Ici, ça se complique un peu (vraiment un peu, ne vous inquiètez pas ). En effet, nous savons:

qu'un signal Qt est une méthode protégée
que le corps d'un signal Qt va associer les informations sur l'objet émetteur (dans le but de permettre l'utilisation de la méthode sender() dans le slot)
que nous ne pouvons pas connecter de fonctions standard à un signal Qt

Nous allons donc mettre en place ici une méthode impliquant la création d'une classe servant d'adaptateur entre les 2 paradigmes (signaux Qt / boost.signals).

class QtClass : public QObject
{
Q_OBJECT
 
public:
    // OBLIGATOIRE si on veut connecter un signal boost à un signal Qt: les signaux sont **protégés**
    void triggerQtSignalEmission(float x)
    {
        emit qtSignal(x);
    }
 
signals:
    void qtSignal(float);
};
 
class QtSignalToStandardCPPBridge : public QObject
{
Q_OBJECT
 
public:
    QtSignalToStandardCPPBridge(QtClass *qc)
    {
        connect(qc, SIGNAL(qtSignal(float)), this, SLOT(onQtSignalEmitted(float)));
    }
 
    template<typename Signature>
    void addStandardSlot(Signature fun)
    {
        sig.connect(fun);
    }
 
private slots:
    void onQtSignalEmitted(float x)
    {
        sig(x);
    }
 
private:
    boost::signal<void (float)>sig;
};
 
class NonQtClass
{
public:
    // fonction normale que l'on appelera depuis un signal Qt en passant par un pont
    void normalFunction(float x)
    {
        std::cout << "In NonQtClass::normalFunction(), x=" << x << std::endl;
    }
 
    // Et une autre pour le fun
    void displaySquareRoot(float x)
    {
        std::cout << "In NonQtClass::displaySquareRoot(), sqrt(x)=" << std::sqrt(x) << std::endl;
    }
 
public:
    void QtSignalToStandardFunction(QtClass *qc)
    {
        QtSignalToStandardCPPBridge adapter(qc);
        adapter.addStandardSlot(boost::bind(&NonQtClass::normalFunction, this, _1));
        adapter.addStandardSlot(boost::bind(&NonQtClass::displaySquareRoot, this, _1));
        // On déclenche ici manuellement l'émission du signal Qt
        qc->triggerQtSignalEmission(121.0f);
    }
};
 
int main(int argc, char **argv)
{
    NonQtClass nqc;
    QtClass    qc;
 
    nqc.QtSignalToStandardFunction(&qc);
 
    return 0;
}

Sortie obtenue:

In NonQtClass::normalFunction(), x=121
In NonQtClass::displaySquareRoot(), sqrt(x)=11

Initiation à Qt Jambi

Visiteur — Sun, 25 Nov 2007 22:05:00 +0100

Ce tutoriel vous permettra de découvrir le fonctionnement de Qt Jambi progressivement.

Version : Jambi
Auteur : Natim

Ce tutoriel est disponible sur le site du zéro: y accéder.

L'utilisateur découvrira:

Comment installer Jambi
Comment créer une fenêtre de base en utilisant des layouts
Le fonctionnement des signaux et slots de Qt
et pour finir, réalisera un petit éditeur de texte et un visualisateur d'images.

Au secours, mes slots ne fonctionnent pas

lud42fr — Fri, 22 Jun 2007 22:20:00 +0200

Une liste de points à appliquer pour réussir ses connexions entre signaux et slots.

Version : Qt3, Qt4
Auteur : Ludo (lud42fr)

Don't panic

Premier diagnostic:

Lorsque qu'un slot n'est pas appelé, il y a trois solutions :

Je n'ai pas lu la doc et je le regrette
Le signal n'est pas émis et ce document est trop général pour répondre à ce cas !
Le slot est mal connecté et le chapitre suivant décrit les bons réflexes

Premiers réflexes:

Rester détendu
Vérifier sur la console les messages d'erreur
Vérifier que la classe débute par la macro Q_OBJECT
Vérifier, en cas d'héritage multiple, que la première classe héritée est un descendant de QObject
Vérifier la syntaxe de la connexion
Vérifier que les signatures sont correctes
Vérifier que la signature du signal est la même que celle du slot

L'action au ralenti

Mettre un grand coup de latte dans l'UC, ça ne corrige pas le problème, mais ça permet de l'aborder détendu.
Vérifier sur la console (voir activer la console en annexe A), que Qt ne signale pas une ou plusieurs erreurs concernant la connexion à l'exécution (les erreurs de connexion n'apparaissent qu'a l'exécution)

Les messages peuvent prendre plusieurs formes et tenir sur plusieurs lignes, mais ont tous en commun, le fait de débuter par Object::connect: Par exemple l'affichage pour une seule connexion défaillante:

Object::connect: Parentheses expected, slot MainWindow::''
   Object::connect:  (sender name:   'test')''
   Object::connect:  (receiver name: 'WindowMain')

Vérifier que la classe débute par la macro Q_OBJECT :

La classe qui contient le slot (ou le signal d'ailleurs) doit débuter par la macro Q_OBJECT. Ce mot clé est repéré par le meta-object-compiler (moc) et permet de générer le code nécessaire à la recherche et à l'identification des slots, code qui sera utilisé par la méthode connect. Ex:

class maClasse : public QObject
   {
    Q_OBJECT
    public:
   };

Vérifier, en cas d'héritage multiple, que la première classe héritée est un descendant de QObject :

Erreur classique lorsqu'on utilise une interface (classe abstraite, n'héritant pas de QObject), elle est difficile à trouver. Pour l'éviter, il suffit de prendre l'habitude de toujours mettre la classe descendant de QObject en premier. Par exemple, ceci donnera une erreur :

class maClasse : public MonInterface, public QObject
   {
    Q_OBJECT
    ...
   };

Il suffit alors de changer l'ordre d'héritage pour que ça marche:

class maClasse : public QObject, public MonInterface
   {
    Q_OBJECT
    ...
   };

Vérifier dans le code, que la syntaxe de la connexion est correcte :

pour cela on rappelle la méthode connect (la plus courante) :
connect(pointeur_sur_l_objet_emetteur, SIGNAL(signature_du_signal),pointeur_sur_l_objet_receveur, SLOT(signature_du_slot));
A noter qu'il est possible de connecter un signal à un autre signal, le principe reste le même :
connect(pointeur_sur_l_objet_emetteur, SIGNAL(signature_du_signal_emetteur),pointeur_sur_l_objet_receveur,SIGNAL(signature_du_signal_receveur));

Passons pointeur_sur_l_objet_emetteur et pointeur_sur_l_objet_receveur, trivial Par contre attardons nous sur la signature d'une méthode : par exemple :

class maclasse
    {
       void ma_methode(int argument1,char* argument2);
    };

la signature de ma_methode est : ma_methode (int,char*)
Si on généralise une signature de méthode c'est : le_nom_de_la_methode ( le_type_de arg1,...,le_type_de_argN)

Vérifier que les signatures sont correctes (ça s'appelle enfoncer le clou !)

Donc on ne met pas le nom des arguments, juste leur type

connect(a, SIGNAL(mon_signal(int)),b, SLOT(mon_slot(int argument)));

Et on met encore moins de valeurs

connect(a, SIGNAL(mon_signal(42)),b, SLOT(mon_slot(int)));

Vérifier que la signature de mon signal est la même que celle de mon slot :

C'est a dire que mon slot a les mêmes types d'arguments et le même nombre d'arguments que mon signal
note: il est possible que le slot ait moins d'arguments que le signal, mais dans un soucis de clarté, ce doc fait l'impasse la dessus !

Vérifier qu'il n'y a pas faute de copier/coller, de parenthèses ou de caractères en trop dans SIGNAL() et SLOT().

En effet SIGNAL() et SLOT() sont des macros qui, entres autres, convertissent leur contenu en chaine de caractère. Dans ce cas une erreur de syntaxe, ne provoque pas d'erreur à la compilation.

Ca ne marche toujours pas :

Alors une âme charitable pourra sûrement se pencher sur le problème (forum)

Annexes

Activer la console

La console est la sortie que Qt privilégie pour afficher ses messages d'erreurs.

Sous les systèmes un*x like, cette dernière est active par défaut, et pour visualiser les traces il suffit, d'exécuter son application depuis un shell ou se référer a la doc de son IDE afin de capturer la sortie standard.
Sous les systèmes win32 il faut ajouter dans le fichier .pro du projet :

CONFIG += console

puis recompiler l'application.

Les traces seront alors affichées dans une console ouverte en parallèle de l'application si celle-ci n'est pas lancée depuis la ligne de commande. Dans ce dernier cas, les traces sont affichées dans la console ayant servi à l'appel

Ouverture d'une boîte de dialogue à partir de la fenêtre principale

IrmatDen — Sun, 15 Apr 2007 18:24:00 +0200

Ce tutoriel est destiné aux nouveaux venus à Qt qui cherche à savoir comment ouvrir une fenêtre à partir de leur fenêtre principale. Nous verrons 2 façons de faire:

utilisation d'une fenêtre principale avec menus pour ouvrir une boîte de dialogue et une boite "A propos..."
ouverture d'une fenêtre de dialogue par le biais d'un bouton

J'en profiterais pour aborder très brièvement 2 autres points : l'utilisation de QAction et les 2 modes d'affichage des boîtes de dialogue.

Version : Qt4 (et une version pyQt disponible)
Auteur : Denys Bulant (IrmatDen), alteo_gange pour la version pyQt
Fil de discussion : Forum

Pré requis:

une installation de Qt4 fonctionnelle
une connaissance minimale du principe des signaux/slots avec Qt

Une introduction aux boîtes de dialogue

Les boîtes de dialogue sont des composants essentiel à la très grosse majorité des applications. Qu'il s'agisse de boîte de configuration ou de fournir une interactivité à un niveau plus ou moins bas avec le document ouvert (par exemple, la recherche dans un traitement de texte ou un tableur), vous aurez souvent l'occasion d'en utiliser.

On distingue 2 types d'utilisation des boîtes de dialogue:

non modale: l'utilisateur peut continuer d'interagir avec le reste de l'application
modale: l'utilisateur est obligé de fermer la boîte de dialogue affichée avant de pouvoir à nouveau se servir de l'application

Chaque usage à son but; par exemple, une boîte de dialogue permettant une recherche dans un document aura tout intérêt à être non modale par souci d'ergonomie. Par contre, une fenêtre de configuration devrait plutôt être modale, dûe à une éventuelle dépendance du résultat sur le comportement de l'application.

A propos de ce tuto

Ce tuto vous permettra, je l'espère de vous familiariser avec QDialog principalement, et plus globalement l'ouverture de fenêtre à partir d'une autre. Je fourni ici 2 approches:

la première est l'ouverture d'une fenêtre en appuyant sur un bouton: elle est la méthode la plus simple, mais pas forcèment la plus commune
la seconde fait utilisation d'un menu, et vous montre comment afficher une boîte de type "A propos...". Il y est fait appel à 2 concepts supplémentaires: les menus et les actions. Le code est loin d'être compliqué, mais assurez-vous d'avoir compris la première partie pour lire la seconde.

Comme dit dans l'introduction, une version pyQt a été réalisée par alteo_gange. Elle est disponible sur le forum.

Partie 0: Lectrice/Lecteur, voici QDialog; QDialog, voici ton futur maître ;-)

Avant de sauter dans le vif du sujet, faisons plus ample connaissance avec la classe QDialog. Vous vous en doutez probablement, elle réalise ce qu'une boîte de dialogue est sensée faire, et permet quelques raccourcis que vous n'auriez pas si vous dériviez d'un QWidget.

Cette section sert de très brève introduction aux fonctions les plus basiques de QDialog. Je vous invite à aller lire la description détaillée sur la page de documentation de Trolltech. Ils en parlent bien mieux que moi.

De la modalité et différences entre les fonctions d'affichage

Afficher une instance de QDialog peut se faire de plusieurs façons. En voici un aperçu:

QDialog::show(): QDialog::show(): utilisé pour un affichage de la boîte de dialogue; par défaut l'affichage est non modal; peut servir à afficher un QDialog de façon modale si setModal(true) à été appellé précédemment.
QDialog::hide(): permet de cacher une boite de dialogue
QWidget::setVisible() et QWidget::isVisible(): QDialog dérive de QWidget, et fournit donc cette alternative à show()/hide(). L'utilité de ces fonctions se trouve principalement dans la possibilité de changer la visibilité d'une fenêtre en une ligne de code.
QDialog::exec(): sert à afficher une boite de dialogue modale et éventuellement récupérer le code de retour

Valeurs de retours

Il peut être parfois utile de savoir si l'interaction demandée à l'utilisateur par le biais de votre boîte de dialogue à réussi ou échoué (dans le cas d'une boîte modale). QDialog::exec() renvoit un code d'erreur qui est soit QDialog::Accepted, soit QDialog::Rejected (ou encore une de vos valeurs propres dans des cas peu courants). La première valeur signifie un succès, tandis que la seconde indique soit un échec, soit un refus ou une annulation. Du côté de votre boîte de dialogue, vous pouvez renvoyer ces valeurs de diverses façons:

QDialog::accept(): QDialog::Accepted sera la valeur renvoyée par exec()
QDialog::reject(): QDialog::Rejected sera renvoyée
QDialog::done(int): vous permet de spécifier l'une des 2 valeurs, mais aussi de spécifier la votre si vous en avez un réél besoin (utilisation assez rare tout de même).

Une boîte de dialogue...

La classe définie ici sera celle que nous allons afficher dans les 2 exemples suivant. Elle n'est composée que d'un bouton "Fermer".

class Dialog : public QDialog
{
public:
	Dialog(QWidget *parent=0)
	:QDialog(parent)
	{
		// Elle est simplement composé d'un bouton "Fermer"
		QPushButton *closeBtn = new QPushButton("Fermer", this);
 
		// lequel ferme la fenetre lorsqu'on clic dessus
		connect(closeBtn, SIGNAL(clicked()), this, SLOT(accept()));
	}
};

Partie 1: ouverture de fenêtre avec des boutons

Classes abordées:

QDialog: sert de classe de base aux boîtes de dialogue
QPushButton: déclenche l'affichage des boites de dialogue, et quitte l'application

Description de la solution

Bien que rarement utilisée/utilisable à cause du "clicodrome" qui risque d'être engendré (affichage d'une boîte de dialogue qui en appelle une autre qui... :)), cette méthode permet d'illustrer simplement l'ouverture d'une boîte de dialogue. Ceci dit, il peut toujours y avoir besoin d'une telle utilisation, ne serait-ce que parce que votre widget principal ne possède pas de menu.

Exemple

Voici la classe principale. C'est à partir de celle-ci que nous allons demander l'ouverture d'une instance de Dialog

class MainDialog : public QDialog
{
	Q_OBJECT
 
public:
	MainDialog(QWidget *parent=0)
	:QDialog(parent), dlg(0)
	{
		dlg = new Dialog(this);
 
		// Ce bouton nous permettra d'afficher notre boîte de dialogue
		QPushButton *modalDlgBtn = new QPushButton(" Open Modal dialog", this);
 
		// J'agrandis la fenetre pour que dlg soit visuellement différenciable de celle-ci
		resize(250,50);
 
		// On demande à Qt d'executer showDialogModal() lorsque le bouton est clique
		connect(modalDlgBtn, SIGNAL(clicked()), this, SLOT(showDialogModal()));
	}
 
private slots:
	void showDialogModal()
	{
		// on affiche la boite de dialogue de facon modale
		dlg->setModal(true);
		dlg->show();
	}
 
private:
	Dialog *dlg;
};

Partie 2: utilisation d'une fenêtre principale avec menus pour ouvrir une boîte de dialogue et une boite "A propos..."

Classes abordées:

QMainWindow: nous en dériverons pour créer une fenêtre principale avec barre de menu
QDialog: sert de classe de base à notre boîte de dialogue
QMessageBox: affichage d'un message "A propos..."
QAction: permet de centraliser et coordonner le comportement et l'apparence entre des choix de menus ou des boutons sur une barre d'outils (chose que nous ne verrons pas ici)

Description de la solution

Nous allons utiliser ici un menu pour permettre d'ouvrir une boîte de dialogue de façon modale, non modale, et enfin une descrption de ce petit code. La classe QAction permet d'ajouter des fonctionnalités à un menu, ainsi qu'à d'éventuelles barre d'outils.

Exemple

C'est à partir de l'interface décrite ci-dessous que nous allons demander l'ouverture d'une instance de Dialog, que ce soit de façon modale ou non.

class MainWindow : public QMainWindow
{
Q_OBJECT
 
public:
	MainWindow(QWidget *parent=0)
	:QMainWindow(parent), dlg(0)
	{
		// Nous creons l'instance de dialogue que nous voulons afficher
		dlg = new Dialog(this);
 
		// Les actions correspondront aux items de menus
		QAction *modelessAct = new QAction("Dialogue non modale", this);
		QAction *modalAct = new QAction("Afficher dialogue modale", this);
		QAction *aboutAct = new QAction("A propos...", this);
		QAction *closeAct = new QAction("Quitter", this);
 
		// Nous créons le menu proprement dit. Nous y ajoutons les actions précédemment crées
		QMenu *menu = menuBar()->addMenu("Divers...");
		menu->addAction(modelessAct);
		menu->addAction(modalAct);
		menu->addAction(aboutAct);
		menu->addAction(closeAct);
 
		// Définition des comportements des actions
		connect(modelessAct, SIGNAL(triggered()), this, SLOT(swapShowDialogModeless()));
		connect(modalAct, SIGNAL(triggered()), this, SLOT(showDialogModal()));
		connect(aboutAct, SIGNAL(triggered()), this, SLOT(about()));
		connect(closeAct, SIGNAL(triggered()), qApp, SLOT(quit()));
	}
 
private slots:
	// Affichée de façon modeless, l'utilisateur peut continuer d'interagir avec le reste de l'application
	void swapShowDialogModeless()
	{
		// Si elle est deja affichee, on cache la boite de dialogue sinon on l'affiche
		dlg->setVisible(!dlg->isVisible());
	}
 
	// En version modale, une boite de dialogue empêche l'utilisateur d'intervenir sur une autre partie
	// de l'interface que la boite de dialogue
	void showDialogModal()
	{
		// On s'assure que notre boite de dialogue n'est pas déjà affichée de façon non modale
		if(dlg->isVisible())
		{
			QMessageBox::critical(this, "Erreur", "La boite de dialogue est déjà ouverte. Veuillez la fermer pour l'ouvrir à nouveau.");
		}
		else
		{
			dlg->exec();
		}
	}
 
	// Affichage d'information à propos de ce "logiciel"
	void about()
	{
		QMessageBox::about(this, "Tuto: Menus et dialogues",
			"Cette application est destinée à illustrer:\n" \
			"> l'ouverture de boîte de dialogue\n" \
			"> l'ouverture d'une fenetre \"A propos...\"\n" \
			"> et une rapide introduction à QAction");
	}
 
private:
	Dialog *dlg;
};

Utilisation du designer avec Qt4

Nicolas — Wed, 04 Apr 2007 21:33:00 +0200

Comment intégrer un widget créé avec le designer ?
Comment utiliser les fichiers .ui créés par le designer ?
Quelle est la différence entre les trois méthodes d'intégration?

Cet article va détailler l'utilisation du designer et l'intégration d'un widget créé avec le designer dans notre programme. Cet article est une adaptation libre de la documentation de Qt : Using a Component in Your Application.

Version : Qt4 (supérieur ou égal à Qt 4.1)
Auteur : Nicolas Arnaud-Cormos (nikikko)
Test : Linux (Qt 4.2)

Introduction

Depuis Qt4, le designer a repris sa fonction première : la création WYSIWYG de forms(terme générique pour désigner soit une fenêtre principale, soit une boîte de dialogue, soit un widget personnalisé). L'utilisation du designer en lui-même et les différences entre ces forms ne seront pas abordés ici.

Une fois que l'utilisateur a créé une form et l'enregistre sur le disque, il crée un fichier .ui qui n'est autre qu'un fichier XML décrivant la form :

widgets qui composent la form
organisation (layout) et position des différents widgets
connexions entre les différents widgets
...

Ce fichier .ui n'est pas directement compilable : pour être utilisé, il doit être converti en fichier C++ à l'aide de l'outil uic. Avec l'utilisation combinée de uic et de qmake, le code C++ est généré automatiquement lors de la compilation de l'application.

Il existe trois méthodes différentes pour intégrer les forms créées avec le designer. Pour l'exemple, vous pouvez utiliser n'importe quelle form, vous en trouverez une en annexe de cet article (qui s'appelle mywidget.ui) :

Fichier généré

Le fichier généré par uic n'est pas un QWidget (ou QMainApplication/QDialog), mais c'est juste une classe de description de l'interface contenant le code de création et d'organisation des widgets, ainsi que les connexions définies dans le designer.

Par exemple, à partir du fichier mywidget.ui :

un fichier ui_mywidget.h va être créé,
ce fichier contient une classe dans le namespace Ui : Ui::MyWidget (pour rappel, MyWidget est le nom que j'ai donné à la form dans le designer),
cette classe contient une fonction importante : void setupUi(QWidget *MyWidget).

Méthode directe

La méthode directe est relativement simple : un widget va être créé pour servir de conteneur à notre form. Voici le .pro utilisé.

TEMPLATE    = app
FORMS       = mywidget.ui
SOURCES     = main.cpp

Note : il ne faut pas indiquer le fichier créé par uic, ici ui_mywidget.h, ce dernier étant implicitement déclaré par le FORMS

La fonction main va créer un widget qui servira de conteneur à l'interface : c'est la ligne ui.setupUi(window);. Voici le fichier complet :

#include <QApplication>
#include "ui_mywidget.h"
 
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    QWidget *window = new QWidget;
    Ui::MyWidget ui;
    ui.setupUi(window);
 
    window->show();
    return app.exec();
}

Bien que rapide et simple d'utilisation, cette méthode est très limitée car elle ne permet pas de définir des signaux et slots, de connecter des éléments entre eux... cette méthode est utile pour des fenêtres statiques, comme par exemple des fenêtres A propos.

Méthode héritage simple

Ici, plutôt que de créer un widget puis de lui appliquer une interface à l'aide de la fonction setupUi, nous allons créer une classe qui hérite de QWidget (ou QDialog/QMainWindow, en fonction du type de form créée) et lui appliquer l'interface dans le constructeur : une instance de la classe Ui::MyWidget est déclarée comme membre de notre classe.

#include "ui_mywidget.h"
#include <QWidget>
 
class MyWidget : public QWidget
{
    Q_OBJECT
 
public:
    MyWidget(QWidget *parent = 0);
...
private:
    Ui::MyWidget ui;
};

Il est toujours nécessaire d'appeler la fonction setupUi, mais cette fois-ci dans le constructeur de notre classe MyWidget :

MyWidget::MyWidget(QWidget *parent)
    : QWidget(parent)
{
    ui.setupUi(this);
}

L'avantage ici, c'est que la déclaration de l'interface est un membre de la classe, les différents widgets ainsi que les layouts/signaux/méthodes sont donc directement accessible dans notre classe MyWidget. Nous allons par exemple ajouter un slot clickMe() qui sera connecté sur un clic sur le bouton Cliquez moi !! (qui porte bien son nom) :

MyWidget::MyWidget(QWidget *parent)
    : QWidget(parent)
{
    ui.setupUi(this);
    connect(ui.pushButton, SIGNAL(clicked()), this, SLOT(clickMe()));
}
 
void MyWidget::clickMe()
{
    ui.lineEdit->setText("YEAH !!!");
}

Note : remarquez ici que tous les widgets qui composent la form sont appelés à l'aide du membre ui.

Cette méthode offre de nombreux avantages au développeur :

accès aux différents widgets de la form,
encapsulation de l'interface dans un widget facilement utilisable,
possibilité d'utiliser plusieurs interfaces...

A propos des noms

Comme vous l'avez remarqué, j'ai employé le même nom partout :

3 fichiers : mywidget.ui, mywidget.h et mywidget.cpp,
dans le designer, l'interface s'appelle MyWidget et lors de la compilation, la classe Ui::MyWidget est créée,
la classe dérivée s'appelle aussi MyWidget (pas de problème de nommage, la classe précédente étant dans un namespace).

C'est une préférence personnelle, mais il est tout à fait possible d'utiliser des noms différents entre l'interface et la classe dérivée. On peut par exemple imaginer deux classes différentes qui partagent la même interface.

Compilation

Il est nécessaire de modifier notre fichier .pro utilisé pour la compilation, en ajoutant la classe créée :

TEMPLATE    = app
FORMS       = mywidget.ui
SOURCES     = main.cpp \
              mywidget.cpp
HEADERS     = mywidget.h

Note : il ne faut pas indiquer le fichier créé par uic, ici ui_mywidget.h, ce dernier étant implicitement déclaré par le FORMS

Méthode héritage multiple

Cette méthode est très proche de la méthode précédente (les notes sur le choix des noms et sur la compilation sont toujours valables), la différence étant que l'interface n'est plus un membre de la classe héritée, mais elle est aussi héritée par le widget :

#include "ui_mywidget.h"
#include <QWidget>
 
class MyWidget : public QWidget, private Ui::MyWidget
{
    Q_OBJECT
 
public:
    MyWidget(QWidget *parent = 0);
};

Nous avons effectué un héritage privé, pour ne pas exposer l'interface dans les éventuelles sous-classes de notre classe. Mais nous pourrions très bien faire un héritage protégé ou publique afin qu'elle soit accessible.

Là encore, il est nécessaire d'appeler la méthode setupUi, mais les méthodes et les widgets sont directement accessibles dans le code du widget (il n'est plus nécessaire d'utiliser ui) :

MyWidget::MyWidget(QWidget *parent)
    : QWidget(parent)
{
    setupUi(this);
}

Personnellement, c'est ma méthode préférée : elle offre une meilleure lisibilité du code, par contre il n'est plus possible de modifier l'interface (mais était-ce vraiment un problème ?).

Connexions automatiques

Depuis Qt4, il n'est plus possible de créer des slots directement dans le designer et de les connecter graphiquement... il est donc nécessaire de définir la connexion dans le constructeur (comme nous l'avons fait pour la méthode héritage simple). Mais il est possible de définir des connexions automatiques avec des noms de slots utilisant une certaine convention :

 on_<nom du widget>_<nom du signal>(<paramètres du signal>);

Lors de la compilation de la form par uic, il génère le code nécessaire à la création automatique des connexions. Dans notre exemple, nous aurions pu utiliser le slot suivant :

void MyWidget::on_pushButton_clicked()
{
    ui.lineEdit->setText("YEAH !!!");
}

Documentation Qtfr - signaux-slots

Interaction entre boost.signals et les signaux/slots Qt

Pré requis:

Introduction

Précautions et conflits

Interaction boost.signals et signaux/slots Qt

Utilisation d'un boost.signal connecté à un slot Qt

Utilisation d'un boost.signal connecté à un signal Qt

Utilisation d'un signal Qt connecté à une (ou des) fonction(s) C++ standard par le biais de boost.signals

Initiation à Qt Jambi

Au secours, mes slots ne fonctionnent pas

Don't panic

Premier diagnostic:

Premiers réflexes:

L'action au ralenti

Ca ne marche toujours pas :

Annexes

Activer la console

Ouverture d'une boîte de dialogue à partir de la fenêtre principale

Pré requis:

Une introduction aux boîtes de dialogue

A propos de ce tuto

Partie 0: Lectrice/Lecteur, voici QDialog; QDialog, voici ton futur maître ;-)

De la modalité et différences entre les fonctions d'affichage

Valeurs de retours

Une boîte de dialogue...

Partie 1: ouverture de fenêtre avec des boutons

Classes abordées:

Description de la solution

Exemple

Partie 2: utilisation d'une fenêtre principale avec menus pour ouvrir une boîte de dialogue et une boite "A propos..."

Classes abordées:

Description de la solution

Exemple

Archive

Utilisation du designer avec Qt4

Introduction

Fichier généré

Méthode directe

Méthode héritage simple

A propos des noms

Compilation

Méthode héritage multiple

Connexions automatiques