Documentation Qtfr - version_Qt4

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

Utilisation de PyQt avec Qt 4.4

Visiteur — Thu, 01 May 2008 15:14:00 +0200

Tool69 vous propose, étape par étape, d'utiliser PyQt avec Qt4.4 RC1.

Version : Qt4/PyQt4
Auteur : Tool69

Le document est disponible en 2 formats:

Voir la page sur le blog de l'auteur
libre téléchargement en PDF : téléchargez.

Introduction aux MVC et création d'un modèle hiérarchique simple

Guid — Sun, 16 Dec 2007 17:02:00 +0100

Ce document présente le concept général de MVC, puis s'attarde sur celui de Qt 4 et enfin, une mise en oeuvre simple du QAbstractItemModel est expliquée en détail et est basée sur sur l'exemple officiel Qt "simpletreemodel".

Version : Toutes versions à partir de Qt 4.0 (exemple fait avec C++/Qt 4.3.3)
Auteur : Guillaume -Guid- DENRY (sur le forum, Azuriel)

Présentation

L'affichage et la manipulation de données est une problèmatique aussi vieille que l'informatique elle-même. En 1979, une tentative de formalisation de ce domaine aboutit au concept de MVC (littéralement Modèle-Vue-Controlleur) qui prend tout d'abord naissance dans le monde smalltalk, et qui permet de dissocier les données de la présentation ainsi que de la logique de contrôle. Cette stratégie permet un découpage clair des concepts et de leurs implémentations, mais surtout une factorisation du code; le fameux concept DRY cher à Ruby, ainsi, alors que le modèle est entièrement dévoué à fournir des données et à en accepter, la vue est uniquement concentrée sur la façon d'afficher les données (c'est la partie émergée de l'iceberg pour l'utilisateur de l'application) tandis que le controlleur, tel un arbitre, se charge de synchroniser les évènements entre le modèle et la vue.

Qt 4 a choisi d'utiliser ces concepts au sein de plusieurs de ses composants de manipulation et d'affichage de données. Dans la bibliothèque de Trolltech, le C du MVC se retrouve combiné au V pour des raisons de praticité et on parle ainsi de ''Modèle/Vue''. A ces concepts se voit adjoint celui de delegate qui définit concrètement la façon dont sont présentées et éditées les données (par exemple via une liste déroulante, une cellule d'édition, etc).

On trouve plusieurs composants de type "vue" ; voici ceux que l'on peut trouver dans la dernière version de Qt 4 au moment où est écrit ce tutoriel (4.3.3) :

Le QTableView qui permet d'afficher un ensemble de données sous forme de tableau et sans notion de hiérarchie.
Le QTreeView modélise un ensemble de données hiérarchisées sous forme d'arbre.
Le QListView affiche des données sous forme de liste, exactement comme le mode "liste" d'un explorateur de fichiers.
Le QColumnView qui affiche une succession de QListViews pour afficher une hiérarchie, à l'instar de Finder, le fameux navigateur de fichiers de MacOSX ou de celui de l'Ipod.

Il est à noter que tous ces composants trouvent leurs équivalents déjà affectés de modèles simples et qui peuvent être amplement suffisants pour un usage de base. Si vous cherchez un moyen simple d'afficher des données sans vous soucier d'optimisation, de maintenabilité, de paramétrage fin et si concevoir un système MVC ne vous séduit pas plus que cela, ce tutoriel n'est peut-être pas tout-à-fait indiqué et vous devriez peut-être vous pencher sur les QTableWidget/QTreeWidget/QListWidget qui offrent déjà pas mal de possibilités.

L'utilisation des modèles dans Qt passe systématiquement par l'héritage d'un des modèles Qt dont l'ancêtre commun est toujours la classe abstraite QAbstractItemModel.
La plupart du temps, vous n'aurez pas besoin d'hériter des vues ainsi que de définir de nouveaux delegates (ni même vous en soucier pour ces derniers); ceux qui existent déjà suffisent pour la plupart des usages. Néammoins, ce besoin pourra se faire sentir dans certaines circonstances, c'est pourquoi l'écriture d'un delegate particulier et son intégration au sein d'une vue sera abordé dans un autre tutoriel.

Le concept de MVC est abondamment expliqué dans la documentation officielle Qt et la création d'un modèle simple non hiérarchique est relativement simple à appréhender. Il se peut même que vous n'ayez pas besoin de ce tutoriel car les exemples de Qt en ce qui concerne les modèles/vues sont nombreux et je vous recommande de jeter un oeil aux exemples situés dans le répertoire itemviews du tarball officiel si le parcours d'un tutoriel n'est pas votre tasse de thé.
Ainsi, tout au long de ce document, nous allons nous concentrer sur le QTreeView et sur la création d'un modèle hiérarchique afin d'expliciter quelques points qui peuvent paraître obscures lorsqu'on s'initie à leur création. Nous tâcherons ainsi d'éclaircir le rôle des diverses méthodes virtuelles à hériter obligatoirement (méthodes abstraites) ou de façon optionnelle afin d'affiner le comportement de notre modèle.

Rétro-conception

Puisqu'il va falloir indiquer au modèle où trouver nos données et comment se représenter la hiérarchie de celles-ci, il est crucial d'avoir déjà une idée claire et précise de la façon dont nos données sont agencées en mémoire et ce qui les lie les unes aux autres.
Du côté du modèle, le QModelIndex nous offre un moyen simple de mettre en oeuvre les briques élémentaires de la modélisation de nos données.
Cette classe est le lien entre la donnée élémentaire et le modèle, mais ne se substitue pas à la donnée en elle-même; il est primordial de concevoir une structure de données hiérarchiques interne qui sera utilisée par notre modèle pour créér ses index.
De façon plus formelle, le QModelIndex connaît le modèle auquel il appartient, son père^[1], son numéro de ligne (au sein des enfants de ce père, pas le numéro de ligne absolu dans le modèle) ainsi que son numéro de colonne. Voilà en gros tout dont le modèle a besoin pour construire sa hiérarchie et on expliquera les rôles des autres champs ultérieurement. Pour la suite, pour évoquer le QModelIndex on parlera simplement d'index.

Les structures internes de nos données devront refléter ces propriétés relationnelles, par exemple, il sera indispensable qu'on puisse facilement retrouver le père d'un élément de données. Ranger nos données dans un structure arborescente est donc probablement le meilleur des choix. S'il n'est pas possible de stocker toutes les données en mémoire (typiquement dans le cas d'une base de données), il faudra tout de même pouvoir modéliser ces concepts relationnels "facilement".

Comme nous l'avons vu plus haut, concevoir un modèle dans Qt 4, c'est hériter, directement ou indirectement, de la classe QAbstractItemModel et implémenter un lot de méthodes virtuelles dont certaines sont abstraites et donc doivent être impérativement héritées sous peine d'erreur de la part du compilateur.

Ces fonctions abstraites sont :

QModelIndex index(int row, int column, const QModelIndex & parent = QModelIndex())

C'est un peu l'"usine à index" du modèle. Ici vont être créés puis renvoyés les index en fonction d'un numéro de ligne, de colonne et d'un index père. A chaque fois que l'on aura besoin d'un index quelque part, que ce soit dans le modèle ou à l'extérieur de ce modèle, c'est cette méthode qui sera invoquée (à l'exception de la création des index pères qui seront fabriqués par le biais de la fonction parent()).

QModelIndex parent(const QModelIndex & index)

Cette méthode est utilisée pour retrouver un index père en fonction de son fils. Comme nous l'avons vu plus haut dans l'encadré, cette méthode est directement appelée par la méthode "parent()" de chaque QModelIndex appartenant au modèle.

int rowCount(const QModelIndex & parent = QModelIndex())

Cette fonction renvoie le nombre de lignes de l'index père passé en paramètre qu'on peut assimiler au nombre d'index enfants de ce père. Cette méthode peut également se révéler couteuse et dans ce cas, il est parfois utile d'envisager la redéfinition de la méthode "hasChildren()" (cette méthode fait appel à rowCount() dans son implémentation par défaut) qui permet de signaler au modèle qu'un index a des enfants sans pour autant en spécifier combien, et ainsi par exemple afficher un noeud dans la vue qui, impliquera alors un appel à rowCount().

int columnCount(const QModelIndex & parent = QModelIndex())

Cette méthode renvoie le nombre de colonnes des enfants de l'index père passé en paramètre. Dans la plupart des cas, cette méthode renverra un nombre non dépendant du père.

QVariant data(const QModelIndex & index, int role = Qt::DisplayRole)

C'est probablement la fonction la plus sollicitée pendant la vie du modèle; elle permet de connaître les données à afficher dans la vue en fonction d'un index et d'un rôle.
Les rôles définissent dans les détails la façon dont une donnée est présentée par les vues associées. On peut par exemple invoquer la méthode data() pour demander la valeur du texte à afficher par le biais de Qt::DisplayRole ou alors la couleur de fond de la cellule qui accueuillera le texte avec le paramètre Qt::BackgroundRole, ou si nécessaire, la police de caractère à utiliser grâce à Qt::FontRole.
Les rôles ont été conçus pour être les plus exhaustifs et génériques possibles mais il est possible de les étendre à partir de la valeur Qt::UserRole qui constitue le premier role "utilisateur".
Dans le cas d'une utilisation classique, le rôle essentiel est Qt::DisplayRole car il concerne directement la donnée (très souvent et en particulier ici du texte) à afficher dans la vue.
Il faut également garder à l'esprit que data() étant appelée très fréquemment, il est important de ne pas y trouver de traitements lourds. Typiquement, je ne fais aucun appel aux outils de traduction dans cette méthode, je les déporte dans le constructeur du modèle.

Puisque Trolltech nous fournit déjà des exemples et des démonstrations de qualité, nous allons appuyer ce tutoriel sur la démo simpletreemodel (sur cette page, vous trouverez également une bonne explication en anglais de cet exemple) disponible dans tout tarball Qt (et dans certains paquets) afin d'expliquer en détail l'implémentation du modèle et les choix effectués.

simpletreemodel

Description

Cet exemple charge et affiche le contenu dans un arbre (QTreeView) d'un fichier de type "Sommaire" de livre. Ce fichier est un ensemble de lignes de texte plus ou moins en retrait par le biais de caractères d'espacement. Par exemple, une ligne qui commence par 8 espaces et qui précède une ligne qui débute par 4 espaces sera considérée comme "fille" de la ligne précédente. Chaque ligne de texte est séparée en deux par un ensemble de tabulations, cet ensemble de tabulation permettra de diviser la ligne en deux colonnes dans l'arbre. Ainsi nous avons donc un arbre à deux colonnes décrit au sein d'un fichier texte et dont voici un extrait :

Form Editing Mode                       How to edit a form in Qt Designer
    Managing Forms                      Loading and saving forms
...
    Layouts                             Objects that arrange widgets on a form
        Applying and Breaking Layouts   Managing widgets in layouts

Exécution

Au lancement du programme, un modèle (implémenté dans treemodel.h/treemodel.cpp) est créé avec en paramètre le texte du fichier "default.txt" chargé pour l'occasion. Ce texte est "parsé" (analysé et stocké dans une structure de données) pendant la construction du modèle, ce qui permettra son utilisation immédiate plus tard sans autre forme d'initialisation. Puis, un QTreeView est également créé et on lui affecte le modèle. On attribue un titre à cet arbre puis il est affiché et la boucle d'évènements est lancée; le programme est réellement visuellement disponible à ce moment là et nous pouvons voir à l'écran le QTreeView en action et le manipuler à notre guise.

Analyse

Le stockage des données

Examinons tout d'abord le contenu de treeitem.h/.cpp. La classe TreeItem est conçue pour stocker une hiérarchie de données. Voici ses caractéristiques :

parentItem pointe vers son élément père.
childItems est une liste de pointeurs vers les fils de cet élément.
itemData contient les données de l'élément sous forme de liste de QVariant (qui est le type générique de Qt, voir la documentation).

Pour cet exemple, l'auteur aurait pu se contenter pour itemData d'une liste de QString, mais le QVariant permet d'imaginer un enrichissement de l'exemple afin de pouvoir stocker et afficher des types de données hétéroclytes au sein de la même liste. Il permet surtout d'être directement renvoyé par la méthode data() du modèle sans aucune conversion comme nous le verrons plus tard. A l'image d'une liste chaînée, l'arbre entier est accessible par sa racine et lorsqu'on détruit un TreeItem, ses enfants sont également détruits. Notez à ce titre l'utilisation de qDeleteAll(), fonction bien pratique qui permet de détruire tous les objets pointés stockés dans une structure de données Qt (QList, QVector, etc).

Voilà qui permet de conclure sur cette classe "jumelle" à la hiérarchie des index et qui servira de conteneur de données librement consultable par le modèle de notre vue.

Le modèle

Intéressons-nous maintenant à la classe TreeModel définie dans treemodel.h/.cpp.

La méthode setupModelData() contient le code le plus complexe de l'exemple :-), il analyse le texte en paramètre et en déduit une hiérarchie de TreeItems qu'il lie au noeud parent passé en paramètre. Cette fonction est appelée uniquement dans le constructeur avec rootData préalablement créé. Ce noeud racine sera le point d'accès à l'arbre de données pour le modèle.

En dehors de setupModelData(), le reste des méthodes présentes sont des éléments hérités appartenant au QAbstractItemModel :

La méthode `parent()`

QModelIndex TreeModel::parent(const QModelIndex &index) const
{
    if (!index.isValid())
        return QModelIndex();

Le but de la méthode parent() est de créer et renvoyer un QModelIndex correspondant au père du QModelIndex en paramètre. Si l'index en paramètre est considéré comme orphelin dans l'arbre, alors il convient de renvoyer un index invalide. Dans notre cas, un index racine est un index correspondant à un TreeItem dont le père est rootData. rootData est le seul élément dans tout l'arbre des TreeItem qui n'a aucun QModelIndex correspondant, il sert juste de père ultime référent et donc, les vrais éléments racines de l'arbre affichés à l'écran sont ses enfants directs. parent() est également une méthode publique. Rien que pour cette raison il est important de tester le cas où l'index en paramètre est invalide. Le père d'un index invalide est donc naturellement ... un index invalide, créé par le biais du constructeur vide du QModelIndex.

TreeItem *childItem = static_cast<TreeItem*>(index.internalPointer());
    TreeItem *parentItem = childItem->parent();

internalPointer est une variable qui fait le lien entre l'index et la donnée. Chaque index du modèle sera donc lié à un TreeItem cette liaison est faite à deux endroits du modèle; la méthode index() et la méthode parent(). La première instruction se contente donc de récupérer le TreeItem associé à l'index, en passant par un static_cast, plus rapide qu'un dynamic_cast et suffisant ici. Il existe un autre moyen de lier une donnée à un index, internalId qui est une autre propriété du QModelIndex, utile dans les cas où la donnée serait accessible via un identificateur entier et non un pointeur. (on peut imaginer une clef entière dans une base de donnée, par exemple). La seconde instruction stocke le père du TreeItem prédédemment extrait dans parentItem.

if (parentItem == rootItem)
        return QModelIndex();

Nous avons vu que chaque TreeItem pointe vers son père, si l'élément père est rootItem, alors on considère du point de vue du modèle que l'index correspondant est un noeud racine et donc, on renvoie un QModelIndex invalide.

return createIndex(parentItem->row(), 0, parentItem);
}

createIndex()^[2] est une méthode qui permet de créer en une instruction un QModelIndex attaché au modèle.

La méthode row() du TreeItem renvoie le numéro de ligne de l'élément au sein de ses frères et c'est exactement ce que createIndex attend comme premier paramètre. 0 est passé comme numéro de colonne car le père d'un index est par convention toujours de colonne 0 dans un système hiérarchique conventionnel. Et enfin, parentItem est passé en tant que comme pointeur interne, c'est un des deux endroits dans le code où l'on associe un TreeItem à son QModelIndex.

La méthode `index()`

QModelIndex TreeModel::index(int row, int column, const QModelIndex &parent) const
{
    if (!hasIndex(row, column, parent))
        return QModelIndex();

La méthode index() est publique. Il convient donc de tester ses paramètres afin de résoudre les cas invalides. En particulier, nous aimerions savoir si les paramètres row et column ne sortent pas des limites du modèle et heureusement, pour le savoir, il existe la fonction hasIndex() qui nous renseigne à ce sujet. La documentation étant peu locace pour cette fonction, c'est dans les sources de Qt que nous allons trouver son rôle précis; cette méthode renvoie vrai si et seulement si les paramètres row et column sont compris entre 0 et le nombre maximum de lignes et de colonnes du parent passé en paramètre.

TreeItem *parentItem;
 
    if (!parent.isValid())
        parentItem = rootItem;
    else
        parentItem = static_cast<TreeItem*>(parent.internalPointer());

Ici nous avons besoin de récupérer l'élément de type TreeItem correspondant à l'index que nous allons renvoyer. Nous savons que si le paramètre parent est valide, alors il aura été créé avec parent() et possèdera donc en pointeur interne sur son TreeItem "jumeau" et, dans le cas où parent est invalide, c'est rootItem qui jouera ce rôle.

TreeItem *childItem = parentItem->child(row);
    if (childItem)
        return createIndex(row, column, childItem);
    else
        return QModelIndex();
}

Maintenant que nous avons l'élément père ainsi que le numéro de ligne du fils, il est trivial d'en déduire l'élément fils avec la méthode child(). Par prudence, le retour de cette méthode est testé et createIndex() est à nouveau invoqué puis retourné par la fonction.

La méthode `data()`

QVariant TreeModel::data(const QModelIndex &index, int role) const
{
    if (!index.isValid())
        return QVariant();

Nous retrouvons le même début de scénario que pour les deux méthodes précédemment analysées, data() étant public, la validité de index est éprouvée et un QVariant() invalide est envoyé le cas échéant.

if (role != Qt::DisplayRole)
        return QVariant();

Dans cette démo, la vue ne sollicitera que le texte pour son affichage, et donc, tous les rôles autre que Qt::DisplayRole sont écartés. Pour se faire, un QVariant() invalide est renvoyé et signifie à l'appelant qu'il fait ce qu'il veut: pour un QTreeView, ça sera par exemple d'afficher la couleur de fond par défaut du composant dans le cas du Qt::BackgroundRole.

TreeItem *item = static_cast<TreeItem*>(index.internalPointer());
 
    return item->data(index.column());
}

Nous avons besoin de retrouver l'élément correspondant à l'index, puis de renvoyer la donnée correspondant à son numéro de colonne. La méthode data() renvoie un QVariant et nous voyons ici l'utilité sémantique d'avoir stocké une liste de QVariant au sein du TreeItem plutôt qu'une liste de QString, même si en l'occurrence, le renvoi d'un QString aurait été possible grace à la construction implicite du C++.

La méthode `rowCount()`

int TreeModel::rowCount(const QModelIndex &parent) const
{
    TreeItem *parentItem;
    if (parent.column() > 0)
        return 0;

Nous avons vu plus haut que le père d'un index a par convention son numéro de colonne égal à 0 dans un cas de hiérarchie classique. De la même façon, tout index de colonne strictement supérieur à 0 ne possède aucun fils; ce rôle est dévolu à l'index de colonne 0.

if (!parent.isValid())
        parentItem = rootItem;
    else
        parentItem = static_cast<TreeItem*>(parent.internalPointer());
 
    return parentItem->childCount();
}

Comme pour la fonction data(), il nous faut extraire le TreeItem correspondant à l'index parent. L'appel de rowCount() avec un index invalide signifie que l'utilisateur souhaite le nombre de noeuds racines, dans ce cas, rootItem jouera le rôle de l'élément père. Le nombre d'enfants de l'élément père est alors renvoyé.

La méthode `columnCount()`

int TreeModel::columnCount(const QModelIndex &parent) const
{
    if (parent.isValid())
        return static_cast<TreeItem*>(parent.internalPointer())->columnCount();
    else
        return rootItem->columnCount();
}

Elle est similaire à la méthode rowCount() si ce n'est une difficulté en moins puisque que l'on peut se contenter de renvoyer directement le nombre de colonnes de l'élément attaché à l'index.

Les méthodes `flags()` et `headerData()`

Qt::ItemFlags TreeModel::flags(const QModelIndex &index) const
{
    if (!index.isValid())
        return 0;
 
    return Qt::ItemIsEnabled | Qt::ItemIsSelectable;
}

C'est dans cette fonction que nous allons définir finement le comportement du modèle. Nous lui précisons ici que nous souhaitons pouvoir intéragir avec l'index en paramètre (Qt::ItemIsEnabled), ainsi que le sélectionner (Qt::ItemIsSelectable).

QVariant TreeModel::headerData(int section, Qt::Orientation orientation,
                               int role) const
{
    if (orientation == Qt::Horizontal && role == Qt::DisplayRole)
        return rootItem->data(section);
 
    return QVariant();
}

headerData() est similaire à la fonction data() si ce n'est qu'elle concerne uniquement les entêtes des lignes et colonnes. Pour notre exemple, seule l'entête des colonnes est affichée et nous utilisons donc à cette fin les valeurs de rootItem uniquement dans le cas où l'orientation est Qt::Horizontal.

Conclusion

Pour des raisons de simplicité, j'ai jugé utile de limiter ce tutoriel à l'analyse d'un exemple simple et en lecture seule et de nombreux aspects de la manipulation des modèles/vue n'y sont pas abordés. Par exemple, lorsqu'on veut modifier les données internes, comment avertir le modèle -et donc la vue- que les données ont changées ? Comment rendre le modèle éditable; doit-on utiliser les méthodes d'insertions et de suppression du modèle ou un système alternatif ? L'édition des données est trop basique, je voudrais la changer, comment faire ? Comment construire un système de recherche au sein d'un modèle ? Comment gérer les types Mime ainsi que le drag'n'drop ? Ces questions seront abordées dans un tutoriel plus avancé.

Notes

[1] Si les valeurs renvoyées par row(), column() et model() appartiennent bien en interne au QModelIndex par le biais de champs privés, le champ parent() est en revanche une invocation directe de la méthode virtuelle pure parent() du modèle de l'index. Ceci peut mettre en lumière le rôle de la fonction parent() du modèle et son implication.

[2] Il existe un constructeur du QModelIndex qui accepte à peu près les mêmes paramètres que createIndex() et qui aurait pu prendre sa place mais pour des raisons d'intégrité et de cohérence (pour ne jamais avoir d'index sans modèle référent), ce constructeur est privé; le seul moyen de créer un index valide est de passer par le modèle et donc par une des déclinaisons de createIndex().

Réseau avec Qt4

Visiteur — Fri, 01 Jun 2007 22:36:00 +0200

Comment utiliser les classes réseaux de Qt ?
Comment faire un client/serveur TCP ?
Comment faire un client FTP ?
Comment faire un client HTTP ?

Ce document présente différentes communications réseaux possibles en utilisant les classes de Qt : TCP, FTP et HTTP.

Version : Qt4
Auteur : rocsan

Le document est disponible en libre téléchargement en PDF : téléchargez.

Il présente les différentes façons d'effectuer des communications réseaux avec Qt.

Création d’un client TCP
Création d’un serveur TCP
Création d’un client FTP
Création d’un client HTTP

XML avec Qt4

Visiteur — Sun, 27 May 2007 21:07:00 +0200

Comment lire ou écrire un fichier XML ?
Comment utiliser les méthodes DOM et SAX ?

Ce document présente l'utilisation des méthodes DOM et SAX avec Qt pour la lecture d'un fichier XML.

Version : Qt4
Auteur : rocsan

Le document est disponible en libre téléchargement en PDF : téléchargez.

Il détaille l'utilisation des méthodes DOM et SAX pour la lecture de fichier XML.

Présentation
Ecriture d'un document XML avec la méthode DOM
- Introduction à DOM
- Présentation de l'application
- Codage
Lecture d'un document XML avec la méthode DOM
- Présentation de l'application
- Codage
Lecture d'un document XML avec la méthode SAX
- Introduction à SAX
- Présentation de l'application
- Codage

Dessiner avec Qt4

Visiteur — Tue, 24 Apr 2007 11:02:00 +0200

Quelles sont les primitives de dessin de Qt4 ?
Où peut-on utiliser QPainter ?
Quels sont les réglages et personnalisations possibles lors d'un dessin ?

Ce document offre un excellent aide-mémoire pour tous ceux qui ont besoin d'utiliser le système de dessin de Qt. Basé sur la version 4.3, un grand nombre de fonctions et explications restent néanmoins valables pour des version inférieures de Qt (même Qt3).

Version : Qt4
Auteur : Véronique Lefrere

Le document est disponible en libre téléchargement en PDF : téléchargez.

Il couvre tous les aspects du dessin (primitives, QPainter, personnalisation...) :

Dessiner quoi ?
- Un (ou plusieurs) point(s) sur un plan donné
- Des segments
- Un polygone
- Un rectangle
- Un rectangles (angles arrondis)
- Une Ellipse
- Un Arc de cercle
- Une forme circulaire
- Une corde
- Un chemin
- Une région ou une zone
- Du texte
- Une pixmap ou une image
Dessiner sur quoi?
- Le support
- La region
Dessiner comment ?
- Les pré-réglages de dessin
- La transparence
- L’Anti-crènelage (anti-aliasing)
- Les lignes et contours
- Le remplissage
- Avec du style
- Du texte haut en couleur
- Le Système de coordonnées
- La Conversion des coordonnées logiques en coordonnées physiques (et inversement)

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 !!!");
}

Un conteneur pour MPlayer (utilisation de QProcess)

IrmatDen — Mon, 02 Apr 2007 09:01:00 +0200

Comment visualiser une vidéo dans Qt ?
Comment intégrer MPlayer et Qt ?

Qt, dans son souci de framework généraliste, n'implémente pas toujours tout ce dont on peut avoir besoin, surtout lorsque cela n'est pas d'usage courant. Les vidéos font partie de ce qui n'était pas couvert par Qt (maintenant supporté depuis la 4.4 par le biais de Phonon). Cependant, un grand nombre de librairies et autres backends existent. Nous allons voir comment utiliser l'un d'entre eux: MPlayer.

Version concernée : Toutes versions (exemple fait avec C++/Qt4 et une version pyQt disponible)
Auteur : Denys Bulant (IrmatDen), alteo_gange et egaudrain pour les versions pyQt
Résumé : utiliser MPlayer conjointement à Qt pour afficher une vidéo
Fil de discussion : Forum

Généralité sur MPlayer en tant que backend...

La particularité de MPlayer est de ne pas s'intégrer par le biais d'une api, mais par un process externe. Les applications désirant l'utiliser en tant que tel, doivent communiquer avec lui par le biais de son flux d'entrée. Les flux de sorties (standard/erreur) peuvent bien sûr être analysés pour récupérer diverses infos sur la vidéo ainsi que les réponses à des requêtes pouvant être formulées par votre application.

Voici ce dont vous aurez besoin :

MPlayer installé, et fonctionnel,
La page des options de MPlayer,
Et la liste des options en slave mode pour mplayer (c'est toutes les manip qui vous sont permises, donc considérez ce fichier comme votre référence ;)).

Pour utiliser MPlayer comme backend, il y a 2 arguments à lui passer impérativement:

l'id du widget à utiliser pour le rendu par le biais de "-wid"
"-slave" qui permet de le mettre en mode esclave, d'où le nom ;-)

Exemple de code lançant MPlayer comme backend:

QStringList args;
// On demande à utiliser mplayer comme backend
args << "-slave";
#ifdef Q_WS_WIN
// reinterpret_cast<unsigned int> obligatoire, HWND ne se laissant pas convertir gentiment ;)
args << "-wid" << QString::number(reinterpret_cast<unsigned int>(renderTarget->winId()));
#else
// Sur linux, pas de manip pour Wid :)
args << "-wid" << QString::number(renderTarget->winId());
#endif

A savoir aussi que sur Windows, je n'ai trouvé que directx comme driver de sortie :/ Cela ne concerne pas les autres OS; lors de mon test sur Linux, je n'ai eu aucun driver à spécifier et cela marche nickel.

Et apparemment les seuls drivers compatibles pour un embarquement de MPlayer sous Linux sont xv, x11 et gl. Et sous Linux, il faut faire attention à avoir un widget de taille raisonnable pour contenir la vidéo. En effet, contrairement à Windows, un resize à la volée n'est pas possible :/

Ensuite, le mode esclave permet donc de commander MPlayer pour:

obtenir des infos (ex: get_video_resolution/get_time_length/...)
lui donner un ordre (ex: play/pause/quit/...)

Tout ce qui lui est transmis, doit être terminé par un retour chariot. Si vous demandiez une information, elle sera renvoyée sur la sortie standard, avec un début de ligne propre à chaque commande (ex: get_video_resolution renverra ANS_VIDEO_RESOLUTION='resX x resY')

Exemple complet

Voici un programme proposant les fonctionnalités suivantes:

lecture d'une vidéo
arrêt
avancer/reculer en déplaçant le slider
affiche le log de toutes ce qui sort sur les flux stdout et stderr de mplayer

Vous le trouverez en annexe de ce tuto ; seuls les points essentiels sont repris ici par souci de clarté. Pour vos tests, pensez à changer les valeurs de mPlayerPath et movieFile, en haut du fichier.

Ce n'est pas un frontend complet, mais cela vous permettra de voir fonctionner Qt 4 avec MPlayer en utilisant QProcess :)

Comme dit dans l'introduction, une version pyQt a été réalisée par alteo_gange. Elle est disponible sur le forum. A noter qu'une version multi-plateforme a été postée par egaudrain; le code est dispo à ce post.

class PlayerWidget: public QWidget
{
    Q_OBJECT
 
public:
    PlayerWidget(QWidget *parent =0)
        :QWidget(parent), isPlaying(false)
    {
        [...]
        renderTarget = new QWidget;
        renderTarget->setSizePolicy(QSizePolicy(QSizePolicy::Fixed, QSizePolicy::Fixed));
        renderTarget->setAttribute(Qt::WA_PaintOnScreen);
        renderTarget->setMinimumSize(320, 240);
        [...]
 
        mplayerProcess = new QProcess(this);
 
        [...]
        connect(mplayerProcess, SIGNAL(readyReadStandardOutput()),
            this, SLOT(catchOutput()));
        connect(mplayerProcess, SIGNAL(finished(int, QProcess::ExitStatus)),
            this, SLOT(mplayerEnded(int, QProcess::ExitStatus)));
        [...]
    }
 
protected:
    virtual void closeEvent(QCloseEvent *e)
    {
        [...]
    }
 
    private:
    bool startMPlayer()
    {
        [...]
        QStringList args;
        // On demande à utiliser mplayer comme backend
        args << "-slave";
        // Et on veut ne pas avoir trop de chose à parser  :) 
        args << "-quiet";
 
#ifdef Q_WS_WIN
        // reinterpret_cast<qlonglong> obligatoire, winId() ne se laissant pas convertir gentiment ;)
        args << "-wid" << QString::number(reinterpret_cast<qlonglong>(renderTarget->winId()));
        args << "-vo" << "directx:noaccel";
#else
        // Sur linux, aucun driver n'a été nécessaire et pas de manip pour Wid :)
        args << "-wid" << QString::number(renderTarget->winId());
        log->append("Video output driver may not be necessary for your platform. \
                    Check: http://www.mplayerhq.hu/DOCS/man/en/mplayer.1.html \
                    at the VIDEO OUTPUT DRIVERS section.");
#endif
 
        args << movieFile;
        qDebug(args.join(" ").toUtf8());
 
        // On parse la stdout et stderr au même endroit, donc on demande à "fusionnner" les 2 flux
        mplayerProcess->setProcessChannelMode(QProcess::MergedChannels);
        mplayerProcess->start(mplayerPath, args);
        if(!mplayerProcess->waitForStarted(3000))
        {
            qDebug("allez, cherche le bug :o");
            return false;
        }
 
        // On récupère les infos de base
        mplayerProcess->write("get_video_resolution\n");
        mplayerProcess->write("get_time_length\n");
        [...]
    }
 
    bool stopMPlayer()
    {
        [...]
        mplayerProcess->write("quit\n");
        if(!mplayerProcess->waitForFinished(3000))
        {
            qDebug("ZOMG, ça plante :(");
            return false;
        }
 
        return true;
    }
 
private slots:
    void catchOutput()
    {
        while(mplayerProcess->canReadLine())
        {
            QByteArray buffer(mplayerProcess->readLine());
            log->append(QString(buffer));
 
            // On vérifie si on a eu des réponses
            // réponse à get_video_resolution : ANS_VIDEO_RESOLUTION='176 x 144'
            if(buffer.startsWith("ANS_VIDEO_RESOLUTION"))
            {
                buffer.remove(0, 21);
                buffer.replace(QByteArray("'"), QByteArray(""));
                buffer.replace(QByteArray(" "), QByteArray(""));
                buffer.replace(QByteArray("\n"), QByteArray(""));
                buffer.replace(QByteArray("\r"), QByteArray(""));
                int sepIndex = buffer.indexOf('x');
                int resX = buffer.left(sepIndex).toInt();
                int resY = buffer.mid(sepIndex+1).toInt();
                renderTarget->setMinimumSize(resX, resY);
            }
            // réponse à get_time_length : ANS_LENGTH=45.28
            if(buffer.startsWith("ANS_LENGTH"))
            {
                buffer.remove(0, 11);
                buffer.replace(QByteArray("'"), QByteArray(""));
                buffer.replace(QByteArray(" "), QByteArray(""));
                buffer.replace(QByteArray("\n"), QByteArray(""));
                buffer.replace(QByteArray("\r"), QByteArray(""));
                float maxTime = buffer.toFloat();
                timeLine->setMaximum(static_cast<int>(maxTime+1));
            }
            // réponse à get_time_pos : ANS_TIME_POSITION=2.4
            if(buffer.startsWith("ANS_TIME_POSITION"))
            {
                buffer.remove(0, 18);
                buffer.replace(QByteArray("'"), QByteArray(""));
                buffer.replace(QByteArray(" "), QByteArray(""));
                buffer.replace(QByteArray("\n"), QByteArray(""));
                buffer.replace(QByteArray("\r"), QByteArray(""));
                float currTime = buffer.toFloat();
                timeLine->setValue(static_cast<int>(currTime+1));
            }
        }
    }
 
    void pollCurrentTime()
    {
        mplayerProcess->write("get_time_pos\n");
    }
 
    // Dirige la timeline
    void timeLineChanged(int pos)
    {
        mplayerProcess->write(QString("seek " + QString::number(pos) + " 2\n").toUtf8());
    }
 
    // Play/stop
    void switchPlayState()
    {
        [...]
    }
 
    void mplayerEnded(int exitCode, QProcess::ExitStatus exitStatus)
    {
        [...]
    }
 
private:
    [...]
    QWidget *renderTarget;
    QProcess *mplayerProcess;
    [...]
};

Si vous avez des remarques...

Si vous avez besoin d'un éclaircissement, vous pouvez le faire ici.

Compiler Qt 4 avec Visual C++ 2005

Visiteur — Mon, 26 Mar 2007 21:14:00 +0200

Installation de Qt4 avec Visual C++ 2005

La version Open-Source de Qt4 n'est compatible officiellement sous Windows qu'avec le compilateur mingw. Il est toutefois possible d'utiliser Visual C++.

Sachez toutefois que cette installation n'est pas supporté officiellement.

Auteur : Aurélien Regat-Barrel
Version : Qt4 Windows
Test : Qt 4.1.1

L'article est disponible sur le site de developpez.com : http://arb.developpez.com/qt4/vc++/...

Cet article a pour but de faciliter la compilation Qt/Windows Open Source Edition avec Microsoft Visual C++ 2005. Il présente aussi de manière détaillée le processus de compilation et le principe de configuration de cette bibliothèque.

Vous trouverez également un article sur notre forum : http://forum.qtfr.org/viewtopic.php...

Qt4 et C++ : Programmation d'interfaces GUI

Nicolas — Thu, 15 Mar 2007 14:03:00 +0100

Livre officiel de Trolltech pour la programmation Qt (version 4.1), ce livre est la traduction française de C++ GUI Programming with Qt 4. Il aborde tous les aspects de la bibliothèque : organisation des widgets, évènements, programmation 2D et 3D...

C'est le livre de référence français sur la programmation Qt4.

Informations

Auteurs : Jasmin Blanchette et Mark Summerfield
Editeur : Pearson Education France
Collection : CampusPress | Référence
Langue : français
ISBN : 9782744021404
Pages : 570

Résumé

Voici la traduction française de l'excellent livre C++ GUI Programming with Qt 4, écrit par des experts de la bibliothèque Qt.

Ce livre couvre tous les aspects de la programmation Qt, avec une première partie offrant une approche simple pour le débutant, en détaillant pas à pas la création d'une application complète. La seconde partie détaille les différents aspects de la bibliothèque : organisation des widgets, évènements, programmation 2D et 3D... Enfin, la dernière partie aborde des aspects plus complexes : internationalisation, multi-threading.

Le CD comporte les versions GPL de Qt 4.1.1 sous Windows/Linux/Mac OSX.

Un chapitre du livre est actuellement en libre téléchargement en PDF sur le site de Pearson Education France (ou en annexe ici).

Table des matières

Partie I : Qt : notions de base
- Pour débuter
- Créer des boîtes de dialogue (A télécharger)
- Créer des fenêtres principales
- Implémenter la fonctionnalité d'application
- Créer des widgets personnalisés

Partie II : Qt : niveau intermédiaire
- Gestion des dispositions
- Traitement des événements
- Graphiques 2D et 3D
- Glisser-déposer
- Classes d'affichage d'éléments
- Classes conteneur
- Entrées/sorties
- Les bases de données
- Gestion de réseau
- XML
- Aide en ligne

Partie III : Qt : étude avancée
- Internationalisation
- Environnement multithread
- Création de plug-in
- Fonctionnalités spécifiques à la plate-forme
- Programmation embarquée

Intégration de VLC

lud42fr — Wed, 21 Feb 2007 22:55:00 +0100

Comment intégrer VLC dans une application Qt ?
Comment visualiser une vidéo dans une applicaiton Qt ?

Ce tutoriel va explorer l'intégration de la bibliothèque VLC dans Qt, pour la lecture de fichier.

Version : Qt3, Qt4
Auteur : Ludo (lud42fr)
Status : basé sur la version SVN 0.9.0 de l’API VLC (devrait egalement fonctionner avec une version >= 0.8.6)

Introduction

Qt, dans son souci de framework généraliste, n’implémente pas toujours tout ce dont on peut avoir besoin, surtout lorsque cela n’est pas d’usage courant. Les vidéos font partie de ce qui n’est pas couvert par Qt. Cependant, un grand nombre de librairies et autres backends existent. Nous allons voir comment utiliser l’une d’entre elle: VLC.

Pré-requis

Voici ce dont vous aurez besoin :

Les librairies VLC >= 0.8.6 (Page de téléchargement)
La documentation des fonctions internes de VLC
Il semblerait que VLC soit difficilement compilable sous Visual C++. Comme ce tutoriel suppose de pouvoir lier votre application avec les libraires VLC, les personnes désireuses de développer sous Windows devront utiliser Mingw pour générer leur application.

Pour compiler VLC 0.9.0 (la version actuellement en cours de développement, récupérable depuis le SVN), vous aurez besoin de :

bibliothèque MAD (MPEG Audio Decoder) : http://www.underbit.com/products/ma... ou mettre une option lors du configure pour la désactiver,
FFMpeg : http://ffmpeg.mplayerhq.hu/,
liba52 : http://liba52.sf.net,
libmpeg2 : http://libmpeg2.sf.net.

Lecteur vidéo

Ce tutoriel détaille la manière d'utiliser l'API VLC au travers d'une application Qt.

L’avantage de cette méthode est que le contrôle de VLC est plus simple et précis et ne nécessite pas d’exécuter/piloter un processus externe (contrairement à l'utilisation de MPlayer).

Nous allons créer un petit exemple simple de lecteur vidéo, ce dernier permettant :

d’initialiser VLC,
de charger un flux vidéo,
de naviguer dans la vidéo (avance/retour),
de modifier le volume.

Une image valant mieux qu'un long discours, voici une capture d'écran du résultat final :

Le code de ce tutorial (source + .pro)

Compilation

La compilation de l’exemple nécessite bien entendu les includes et les libraires de VLC. Celles ci doivent êtres dans dans les chemins de recherche

Linux/Unix

Voici le fichier pro typique :

TEMPLATE = app
DEPENDPATH += .
INCLUDEPATH += . 
SOURCES += tuto_vlc.cpp
LIBS+=-lvlc

Explications

Si l'on résume les étapes nécessaires à la lecture d'un vidéo dans une application Qt :

initialiser un contexte VLC,
ajouter un flux à la playlist,
rediriger la fenêtre vidéo de sortie vlc sur un widget Qt de l'application,
démarrer la lecture du flux.

Certaines fonctions de l'API de VLC seront détaillées. Toutes ces fonctions et bien plus encore sont disponibles dans la documentation de VLC.

Initialisation d'un contexte VLC

Normalement seule l'inclusion de l'entête vlc/libvlc.h est nécessaire pour utiliser toutes les fonctions VLC.

#include <vlc/libvlc.h>

VLC reporte toutes ses erreurs dans une structure particulière libvlc_exception_t. Avant tout appel à une fonction VLC, il nous faudra donc une telle structure :

libvlc_exception_t _vlcexcep; //déclaration de la structure
libvlc_exception_init (&_vlcexcep); //initialisation de la structure

Quelques fonctions pratiques à utiliser avec libvlc_exception_t :

if(libvlc_exception_raised(&_vlcexcep)!=0) {....} //teste si une erreur a eu lieu.
libvlc_exception_get_message(&_vlcexcep); //retourne le message d'erreur
libvlc_exception_clear(&_vlcexcep); //efface la/les erreurs précédentes

Il est maintenant temps de créer un contexte VLC, de type libvlc_instance_t, nécessaire à la plupart des fonctions :

libvlc_instance_t *_vlcinstance;
_vlcinstance=libvlc_new(argc,argv,&_vlcexcep);

Il n'est possible de lire qu'un seul flux vidéo à la fois par contexte. Pour lire plusieurs flux en parallèle, il faut donc initialiser plusieurs contextes. Lorsqu'un contexte, n'est plus utile, ne pas oublier de le libérer :

libvlc_destroy (_vlcinstance, &_vlcexcep);

Ajout d'un flux

Le chargement d'un flux vidéo se fait dans un contexte initialisé et dans l'élément playlist de VLC (se réfèrer à la doc quant à la gestion des playlist, ce tutoriel n'en faisant pas d'autres mentions).

libvlc_playlist_clear(_vlcinstance,&_vlcexcep); //on vide la playlist
libvlc_playlist_add (_vlcinstance,URL,NULL,&_vlcexcep);//on ajoute le nouveau flux

Note : à ce niveau, le fichier est dans la playlist, il n'est pas en cours de lecture ou n'a pas interrompu la lecture en cours.

Avec URL une chaine de caractère de la forme (principalement) :

Type	Forme
Fichier local	file://chemin
Url http	http://ip:port/file
Fichier ftp	ftp://ip:port/file
DVD	dvd://[device]
Flux UDP	udp:[]@[][:]%%

Redirection du flux sur un widget Qt

La redirection de la sortie vidéo sur un widget de l'application est une des étapes les plus importantes pour l'intégration (ce n'est pas la plus compliquée ;-) ).

A noter que VLC, se chargera d'adapter la taille de la vidéo à la taille du widget tout en conservant l'aspect de la video (VLC se chargera aussi de resizer la video si la taille du widget venait a changer en cours de lecture).

N'importe quel widget peut servir pour afficher une video, mais dans la mesure ou il sera complètement recouvert, un simple QWidget suffit.

//Notez l'usage de Widget->winId() pour indiquer on dessiner la video
libvlc_video_set_parent(_vlcinstance ,Widget->winId(),&_vlcexcep);

Functions vidéos/audios

Certaines fonctions requièrent un pointeur sur libvlc_input_t .Pour obtenir ce pointeur, un flux doit etre en cours de lecture/pause :

libvlc_input_t *input=libvlc_playlist_get_input (_vlcinstance,&_vlcexcep); //obtenir un pointeur input
libvlc_input_free (input); //il est en general de bon ton de libérer input après usage

Contrôle de la vidéo

Démarrer la lecture :

libvlc_playlist_play (_vlcinstance , -1, 0, NULL, &_vlcexcep);
// avec :
//          -1 pour indiquer de lire l'element suivant de la playlist
//          0 le nombre d'option a passer au flux a lire
//          NULL : les options

Stopper la lecture :

libvlc_playlist_stop (_vlcinstance, &_vlcexcep);

Mettre en pause la lecture :

libvlc_playlist_pause (_vlcinstance, &_vlcexcep);

Connaître l'état :

int etat=libvlc_playlist_isplaying(_vlcinstance, &_vlcexcep);
//etat=0 si stop ou pause
//etat=1 si lecture en cours

Lire en boucle :

int loop=1; //mettre a 0 pour stopper la lecture en boucle
libvlc_playlist_loop (_vlcinstance, loop,&_vlcexcep);

Connaître la durée totale du flux (nécessite un pointeur input) :

long long duree=libvlc_input_get_length (input, &_vlcexcep);

Connaître la position actuelle en ms (nécessite un pointeur input) :

long long position=libvlc_input_get_time (input, &_vlcexcep);

Se positionner dans le flux (position en ms - nécessite un pointeur input) :

libvlc_input_set_time (input, 42000,&_vlcexcep); //se positionne a 42 sec

Connaître la position actuelle en pourcentage (nécessite un pointeur input) :

float posEnPourcent=libvlc_input_get_position (input, &_vlcexcep)*100.0;

Se positionner dans le flux (position en pourcentage du temps total - nécessite un pointeur input) :

libvlc_input_set_position(input, 0.42f,&_vlcexcep); // se positionne a 42% du flux ???

Contrôle du volume

Obtenir la valeur du volume comprise entre 0 et 100 - 0 étant le minimum :

int volume=libvlc_audio_get_volume (_vlcinstance, &_vlcexcep);

Positionner le volume (valeur en 0 et 100) :

libvlc_audio_set_volume (_vlcinstance, 42,&_vlcexcep); //volume a 42%

Intégration de SDL

IrmatDen — Wed, 21 Feb 2007 13:11:00 +0100

Comment intégrer SDL dans un widget Qt ?

Ce tutoriel va explorer l'intégration de la bibliothèque SDL dans Qt, le rendu étant effectué dans un widget Qt.

Version : Qt4 (Qt3 possible avec quelques ajustements)
Auteur : Denys Bulant (IrmatDen)

Pré requis:

La librairie SDL : le site contient une section documentation pour débuter

Un widget Qt comme cible de rendu pour SDL

Les moteurs graphiques des différents Qt ne sont souvent pas adaptés au travail graphique intense (sauf à passer par OpenGL, mais on détourne le problème - c'est d'ailleurs ce que l'on va faire ici).

Signifier à SDL la fenêtre à utiliser

Se servir d'un widget comme zone de rendu cible pour SDL est très simple: il suffit d'une variable d'environnement. Cette variable est SDL_WINDOWID et peut être de 2 formats:

un entier, tel quel
une valeur hexadécimale, préfixé par '0x'

Une variable valide est un handle de fenêtre (dont le format peut varier en fonction de l'environnement utilisé). Ce handle s'obtient par la méthode QWidget::winId(), qui est une méthode publique.

Une fois la zone de rendu définie par cette variable, on peut initialiser le moteur graphique de SDL. Voici par exemple le code permettant de réaliser cette intégration :

char windowid[64];
#ifdef Q_WS_WIN
	sprintf(windowid, "SDL_WINDOWID=0x%lx", reinterpret_cast<qlonglong>(winId()));
#elif defined Q_WS_X11
	sprintf(windowid, "SDL_WINDOWID=0x%lx", winId());
#else
	qFatal("Fatal: cast du winId() inconnu pour votre plate-forme; toute information est la bienvenue!");
#endif
SDL_putenv(windowid);
// Initialisation du système vidéo de SDL
SDL_Init(SDL_INIT_VIDEO);
screen = SDL_SetVideoMode(width(), height(), 32, SDL_SWSURFACE);

Attention : ne le faîtes pas l'initialisation du système vidéo de SDL avant que la création réelle de votre widget (le moment le plus sûr est lors du premier showEvent), sinon une seconde fenêtre sera créée par et pour SDL.

Configuration du widget de rendu

Le dessin direct par SDL sur un widget Qt implique une petite configuration des attributs de dessin du dit widget:

setAttribute(Qt::WA_PaintOnScreen);
setAttribute(Qt::WA_NoSystemBackground);

A faire lors de l'utilisation de SDL, sinon, vous aurez une bouillie de pixels "inspirée" par le fond de l'écran à cet emplacement ;)

Conflit de main

Il y a par contre un conflit entre SDL et Qt au niveau de la fonction main. Lorsque main n'est pas le point d'entrée d'un programme (ce qui est le cas sur win32 par exemple), Qt appelle main à partir de son implémentation de WinMain. SDL quant à lui fait un define (code extrait de SDL_main.h) :

#define main SDL_main
/* The prototype for the application's main() function */
extern C_LINKAGE int SDL_main(int argc, char *argv[]);

Pour supprimer ce problème, ils vous faut annuler la définition de SDL, juste après l'inclusion de SDL.h :

#include "SDL.h"
#undef main

Une fois ceci fait, vous pouvez utiliser sereinement le système vidéo de SDL au sein de votre application Qt :)

Modification du fichier projet

Comme toute librairie, son utilisation avec votre programme doit être expressément signalée sous peine d'erreurs de compilation et/ou de liaison. Les informations à ajouter dans le fichier projet sont :

le chemin vers les en-têtes SDL (ex: INCLUDEPATH += /usr/local/include/)
la librairie avec laquelle lier (et éventuellement son chemin) (ex: LIBS += -L/usr/local/lib/ -lSDL)

Exemple complet

Vous trouverez associé à ce tutoriel un exemple illustrant l'utilisation de la SDL pour un starfield - qui rappellera des souvenirs aux (ex-)possesseurs de vieilles machines et qui ont codé avant l’arrivée du S-VGA (définit comme étant haute-résolution à l’époque) ;-)

J'ai repris ici les points principaux de la classe :

[...]
 
#ifdef Q_WS_WIN
#include <SDL.h>
#elif defined Q_WS_X11
#include <SDL/SDL.h>
#endif
 
/* PIEGE: main est redéfini par SDL.h comme SDL_Main.
                On retire donc la définition puisque Qt le gère
*/
#undef main
 
[...]
 
class SDLWidget : public QWidget
{
    Q_OBJECT
 
public:
    SDLWidget()
    :refreshTimer(0), windowInitialized(false), screen(0), StarNumbers(100)
    {
        [...]
    }
 
    virtual ~SDLWidget()
    {
        SDL_Quit();
    }
 
protected:
    virtual void showEvent(QShowEvent *e)
    {
        if(!windowInitialized)
        {
            // C'est ici qu'on dis à SDL d'utiliser notre widget
            char windowid[64];
#ifdef Q_WS_WIN
 
			sprintf(windowid, "SDL_WINDOWID=0x%lx", reinterpret_cast<qlonglong>(winId()));
#elif defined Q_WS_X11
			sprintf(windowid, "SDL_WINDOWID=0x%lx", winId());
#else
			qFatal("Fatal: cast du winId() inconnu pour votre plate-forme; toute information est la bienvenue!");
#endif
            SDL_putenv(windowid);
 
            // Initialisation du système vidéo de SDL
            SDL_Init(SDL_INIT_VIDEO);
            screen = SDL_SetVideoMode(width(), height(), 32, SDL_SWSURFACE);
            windowInitialized = true;
        }
    }
 
private:
    [...]
 
private:
    [...]
 
private slots:
    void onRefresh()
    {
        if(windowInitialized && screen)
        {
            SDL_LockSurface(screen);
                // Nettoyage de l'écran
                SDL_FillRect(screen, NULL, 0);
                // Dessin du starfield
                drawStarfield();
            SDL_UnlockSurface(screen);
 
            // Rafraîchissement...
            SDL_UpdateRect(screen, 0, 0, 0, 0);
 
            // Et enfin, mise à jour des positions des étoiles
            updateStarfield();
        }
    }
 
private:
    [...]
};

N’oubliez pas d’ajouter les références d’inclusion et de bibliothèques de SDL au .pro, et laissez vous aller à un peu de nostalgie ;-)

Utilisation avancée

L'ensemble du code illustrant l'utilisation décrite ici est disponible sur la seconde pièce jointe.

La méthode décrite précédemment est suffisante si vous n'avez besoin de SDL que dans un seul widget. Mais si vous voulez utiliser SDL comme système d'affichage pour plusieurs widgets, alors il faut changer de stratégie. En effet, SDL ayant pris le parti d'utiliser une seule et unique variable d'environnement pointant vers un et un seul identifiant de fenêtre, il va nous falloir utiliser ce système différemment.

Nous allons donc devoir créer un widget invisible servant à initialiser le système SDL. (Vous trouverez une classe remplissant cette fonctionnalité dans les fichiers tools.h et tools.cpp (classe SDLContext) fournis avec l'archive.) Le dessin se fera alors sur diverses surfaces SDL (au moins 1 par widget où vous comptez l'utiliser en fait).

Il nous font donc aussi des fonctions de conversion entre QImage et SDL_Surface, ainsi qu'une fonction de création de SDL_Surface. Cette dernière est nécessaire afin de paramétrer les surfaces SDL de façon à ce que leur format soit compatible à 100% avec les formats proposés par QImage. Dans l'exemple, ces fonctions ne couvrent pas tout les cas nécessaires, il ne tient qu'à vous de les compléter selon vos besoins:

// Création d'une surface SDL rapidement convertible en QImage
SDL_Surface* createQImageCompliantSurface(Uint32 flags, int width, int height)
{
	static const int Rmask = 0x00FF0000;
	static const int Gmask = 0x0000FF00;
	static const int Bmask = 0x000000FF;
	static const int Amask = 0xFF000000;
 
	return SDL_CreateRGBSurface(flags, width, height, 32, Rmask, Gmask, Bmask, Amask);
}
 
/* Fonctions de conversion entre SDL_Surface et QImage
   SDLSurfaceToQImage **DOIT** recevoir une surface
   construite avec createQImageCompliantSurface
*/
QImage SDLSurfaceToQImage(SDL_Surface *s)
{
	SDL_LockSurface(s);
		QImage im(static_cast<uchar*>(s->pixels), s->w, s->h, QImage::Format_RGB32);
        SDL_UnlockSurface(s);
 
	return im;
}

2 améliorations conseillées:

il est intéressant de définir notre propre type encapsulant ceci afin de réduire à 0 le risque de passer une mauvaise surface.
on peut ajouter une méthode SDLSurfaceToQImage prenant en paramètre une référence vers un QImage afin de modifier les données d'un QImage précédemment créé. Dans les scènes requierant un affichage rapide, cela peut apporter une différence

Nous avons donc un système SDL fonctionnel pour l'appli ainsi que la possibilité d'avoir des surfaces dont la transformation en QImage est extrêmement rapide (puisqu'il s'agit de la copie brute des octets formant la surface). A la différence de la première partie du tutoriel, nous ne dessinons plus sur une surface affichée à l'écran (que nous utilisions ou non le double buffering ne change rien). Il va donc nous falloir surcharger paintEvent pour gérer l'affichage. La mise à jour de notre QImage se fera à chaque mise à jour de la surface. Inutile de le faire dans le paintEvent puisque certains de ces événements seront générés par le système sans qu'il y ait obligatoirement eu de modifications de la surface, par exemple le fait que le widget soit minimisé puis restauré/maximisé.

class Widget : public QWidget
{
protected:
   virtual void paintEvent(QPaintEvent *e)
   {
      QPainter p(this);
      p.drawImage(displayBuffer);
   }
 
   void modificationSurfaceSDL()
   {
      /* on modifie la surface renderer par diverses opérations de dessin */
      displayBuffer = SDLSurfaceToQImage(renderer);
      update(); // on demande par la même occasion un rafraichissement du widget
   }
 
private:
   SDL_Surface *renderer;
   QImage displayBuffer;
};

Voici le screenshot obligatoire présentant l'exemple en cours d'exécution:

C++ GUI Programming with Qt 4

Nicolas — Tue, 20 Feb 2007 09:38:00 +0100

Livre officiel de Trolltech pour la programmation Qt (version 4.1), ce livre est en fait une mise à jour de C++ GUI programming with Qt 3. Il aborde tous les aspects de la bibliothèque : organisation des widgets, évènements, programmation 2D et 3D...

Informations

Auteurs : Jasmin Blanchette et Mark Summerfield
Editeur : Prentice Hall PTR
Collection : Bruce Perens' Open Source Series
Langue : anglais
ISBN : 0131872494
Pages : 560

Résumé

Le second livre officiel de Trolltech, traitant de la programmation Qt4. Ce livre est une mise à jour de C++ GUI Programming with Qt3.

Le CD comporte les versions GPL de Qt 4.1.1 sous Windows/Linux/Mac OSX.

Un chapitre du livre est actuellement en libre téléchargement en PDF sur le site de Prentice Hall.

Table des matières

Part I: Basic Qt
- Getting Started
- Creating Dialogs
- Creating Main Windows
- Implementing Application Functionality
- Creating Custom Widgets

Part II: Intermediate Qt
- Layout Management
- Event Processing
- 2D and 3D Graphics
- Drag and Drop
- Item View Classes
- Container Classes
- Input/Output
- Databases
- Networking
- XML
- Providing Online Help

Part III: Advanced Qt
- Internationalization
- Multithreading
- Creating Plugins
- Platform-Specific Features
- Embedded Programming

Appendices
- Installing Qt
- Introduction to C++ for Java and C# Programmers

Etendre le type QVariant

IrmatDen — Mon, 19 Feb 2007 22:53:00 +0100

Comment étendre QVariant avec ses propres objets ?

Ce tutoriel va nous montrer comment étendre QVariant avec ses propres types.

Version : Qt4
Auteur : Denys Bulant (IrmatDen)

Introduction

QVariant est un type très puissant permettant de stocker n’importe quel type de variable sous une forme abstraite. Depuis Qt4, il est possible d’y rajouter ses propres types, ainsi que celui de librairies tierces. Il y a 2 restrictions :

Connaître le nom du type (facile ;-) )
Dans le cas d’une classe, elle doit répondre aux contraintes suivantes :
- avoir un constructeur par défaut public (ne prenant aucun argument, ou tous les arguments ayant une valeur par défaut),
- avoir un constructeur par copie public (c-a-d MaClasse(const MaClasse&) ),
- avoir un destructeur public.

Il suffit d’ajouter la macro Q_DECLARE_METATYPE(type), après avoir inclus QVariant, et après la déclaration du type. Si le type à gérer est déclaré dans un en-tête que vous ne pouvez/voulez pas toucher (celui d’une bibliothèque tierce par exemple), il suffit de la saisir quelque part après l’inclusion dudit en-tête.

Exemple

Voici un exemple illustrant cette fonctionnalité. Imaginons que nous voulions nous servir de QVariant pour transmettre les données d’un type Vector3 défini dans une lib tierce (bien que les sources soient fournis ici pour éviter les multiples projets...).

Vector3

Ce type est défini dans le fichier suivant vector3.h.

#ifndef VECTOR3_H
#define VECTOR3_H
class Vector3
{
public:
    Vector3() : m_x(0.0), m_y(0.0), m_z(0.0) {}
    Vector3(float x, float y, float z) : m_x(x), m_y(y), m_z(z) {}
    Vector3(const Vector3 &v) : m_x(v.m_x), m_y(v.m_y), m_z(v.m_z) {}
    ~Vector3() {}
 
    float getX() const { return m_x; }
    float getY() const { return m_y; }
    float getZ() const { return m_z; }
 
    void setX(float x) { m_x = x; }
    void setY(float y) { m_y = y; }
    void setZ(float z) { m_z = z; }
 
private:
    float m_x, m_y, m_z;
};
// S'il s'agissait de votre propre classe et que vous vouliez la coupler pour de bon à Qt,
// vous voudriez très probablement ajouter ces 2 lignes:
// #include <QVariant>
// Q_DECLARE_METATYPE(Vector3);
#endif

Utilisation de Vector3 avec QVariant

Pas grand chose à expliquer ci-dessous, la doc citée en début de document illustre la conversion vers et à partir d’un QVariant avec type personnalisé.

#include <iostream>
#include <string>
#include <QVariant>
#include "vector3.h"
// Nous enregistrons le type Vector3 pour son utilisation avec QVariant
// seulement nécessaire si ce n'est pas déjà dans le fichier d'en-tête
Q_DECLARE_METATYPE(Vector3);
using namespace std;
inline void displayVector3(const string &name, const Vector3 &v)
{
    cout << name << "={"
        << v.getX() << ","
        << v.getY() << ","
        << v.getZ() << "}" << endl;
}
int main(int argc, char **argv)
{
    Vector3 v1(1.0, 1.0, 0.5);
    displayVector3(string("v1"), v1);
    QVariant var;
    var.setValue(v1); // var contient donc maintenant v1(1.0, 1.0, 0.5);
    Vector3 v2(5.0, 0.75, 0.25);
    displayVector3(string("v2a"), v2);
    v2 = var.value<Vector3>(); // récupération dans v2 du Vector3 contenu dans var (ie v1)
    displayVector3(string("v2b"), v2);
    cin.get();
    return 0;
}

Centralisons un peu

Voilà une première façon de faire. La récupération du Vector3 contenu dans le QVariant se fait à l’aide d’une fonction template. Pour rendre les choses un peu plus lisible, et/ou si vous prévoyez de gérer un certain nombre de classes de cette façon, on peut tout simplement mettre ces macros à part, et regrouper les méthodes de conversion QVariant vers type personnalisé avec.

En voici un exemple :

#ifndef DECL_METATYPE_H
#define DECL_METATYPE_H
// Doit être inclus pour la macro Q_DECLARE_METATYPE et la définition de la classe Helper
#include <QVariant>
// Pour que Vector3 soit un type connu...
#include "vector3.h"
// Nous enregistrons le type Vector3 pour son utilisation avec QVariant
Q_DECLARE_METATYPE(Vector3);
// Namespace ajoutant des fonctions de conversion à partir de QVariant
namespace QVariantHelper
{
    inline Vector3 ToVector3(QVariant v)
    {
        return v.value<Vector3>();
    }
};
#endif

La seule modification à apporter au main serait la suivante :

[...]
    Vector3 v2(5.0, 0.75, 0.25);
    displayVector3(string("v2a"), v2);
    // remplace l'utilisation d'un template par quelque chose
    // de plus significatif (à mes yeux... ;))
    v2 = QVariantHelper::ToVector3(var);
    displayVector3(string("v2b"), v2);
[...]

Et les pointeurs ?

Quid des pointeurs vers des types personnalisés?

Eux aussi sont transformables en QVariant. Il suffit de les déclarer comme type eux aussi. En voici un exemple :

#ifndef DECL_METATYPE_H
#define DECL_METATYPE_H
#include <QVariant>
#include "vector3.h"
// Nous enregistrons le type Vector3 pour son utilisation avec QVariant
Q_DECLARE_METATYPE(Vector3);
// ... ainsi que le type pointeur vers Vector3
Q_DECLARE_METATYPE(Vector3*);
// Namespace ajoutant des fonctions de conversion à partir de QVariant
namespace QVariantHelper
{
    // renvoit le Vector3 contenu dans v, ou le Vector3 par défaut
    // si la conversion n'est pas faisable
    inline Vector3 ToVector3(QVariant v)
    {
        return v.value<Vector3>();
    }
    // renvoit le Vector3* contenu dans v, ou 0 si la conversion n'est pas faisable
    inline Vector3* ToVector3Ptr(QVariant v)
    {
        return v.value<Vector3*>();
    }
};
#endif

Et voici l’assignation d’un pointeur à QVariant et son extraction :

[...]
    QVariant varVec3;
    varVec3.setValue(v1);
    QVariant varVec3Ptr = QVariant::fromValue(&v1); // Notation générique alternative pour l'assignation d'une valeur à un QVariant
    Vector3 v2(5.0, 0.75, 0.25);
    displayVector3(string("v2a"), v2);
    v2 = QVariantHelper::ToVector3(varVec3);
    displayVector3(string("v2b"), v2);
    Vector3 *v3 = QVariantHelper::ToVector3Ptr(varVec3Ptr);
    // TOUJOURS vérifier si v3 est valide avant utilisation !
    if(v3)
        displayVector3(string("v3(ptr)"), *v3);
    else
        cout << "v3 is an invalid pointer to Vector3!" << endl;
[...]

Et enfin, si votre type est une classe dérivant de QObject, vous devez utiliser QPointer : en effet, QObject n'a pas de constructeur par copie.

Pour cela, il faut juste déclarer le metatype avec le QPointer représentant votre classe (ie Q_DECLARE_METATYPE(QPointer<MyObject>)) en plus des déclarations de MyObject et MyObject*.

Attention : QPointer<VotreClasse> et VotreClasse* sont incompatibles !

Création de plugin avec Qt

Nicolas — Sun, 18 Feb 2007 23:11:00 +0100

Comment créer des plugins avec Qt ? et de manière multi-plateforme ?
Comment permettre à mes utilisateurs d'étendre eux-mêmes mon application ?

Ce tutoriel va nous détailler la création d'un système de plugins avec la bibliothèque Qt, et le chargement de ces plugins depuis notre application.

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

Plugin, vous avez dit plugin ?

Qu'est-ce que c'est ?

Je n'ai pas réussit à faire mieux que Wikipedia pour la définition :

En informatique, un plugin ou plug-in, de l'anglais to plug in (brancher), parfois traduit en module externe, module enfichable, module d'extension, greffon ou plugiciel, est un logiciel tiers venant se greffer à un logiciel principal afin de lui apporter de nouvelles fonctionnalités. Le logiciel principal fixe un standard d'échange d'informations auquel ses modules se conforment. Le module n'est généralement pas conçu pour fonctionner seul mais avec un autre programme.

Comment ça marche ?

C'est relativement simple (en théorie ;)) :

Le logiciel principal défini une API standard : un ensemble de classes et de fonctions pouvant être utilisées/héritées par les plugins. C'est le lien, le langage commun entre le logiciel principal et les plugins.
Les plugins se basent sur cette API, et créent ainsi de nouvelles fonctionnalités pour le logiciel principal. Ils se présentent généralement sous forme de bibliothèques dynamiques (*.dll sous Windows ou *.so sous Linux). Pour pouvoir être chargés par le programme principal, ils doivent être copiés dans un répertoire spécifique.
Le logiciel principal, au démarrage, charge les plugins qu'il trouve, ajoutant ainsi de nouvelles fonctionnalités.

Avantages ?

Les avantages d'un système de plugins sont nombreux. En voici quelques uns :

l'utilisateur ou un intervenant externe peut étendre les fonctionnalités d'une application sans avoir son code source,
le logiciel est beaucoup plus modulaire : possibilité de faire des versions réduite, version complète...
la mise en place d'un système de plugin force à réfléchir un peu à l'architecture du logiciel, ce qui n'est pas un mal ;)

Les plugins avec Qt ? (pourquoi c'est pratique)

La mise en place d'un système de plugin est parfois assez lourde et nécessite par exemple de vérifier dans le programme principal si un plugin contient telle ou telle fonction. Je ne parle même pas d'un système multi-plateforme... heureusement, Qt est là.

Grâce à Qt, la réalisation d'un système de plugins multi-plateforme est relativement simple : la documentation Qt sur le système de plugins.

CalcOp

Pour illustrer la création de plugin, nous allons utiliser un exemple assez simple : un petit projet que j'ai nommé calcop, et qui permet à partir de 1, 2 ou 3 variables, d'effectuer une opération au choix de l'utilisateur (par exemple des additions, multiplications, remplacement de caractères dans une chaîne...).

Ça ne sert à rien, mais le principal c'est que l'exemple est très simple, il permet donc de se concentrer sur le code lié à la gestion de plugin. Le code source est livré avec deux plugins :

un plugin contenant des opérations mathématiques (addition, multiplication, division, soustraction, factoriel)
un plugin contenant des opérations sur les chaînes (inversion de sens et remplacement dans une chaîne)

Les sources du logiciel sont téléchargeables ici. Je vous conseille de les télécharger avant de vous lancer dans la lecture du tutoriel.

Le programme principal

Le programme principal est relativement simple. Je ne vais pas détailler tout le code, mais je vais me focaliser sur les parties nécessaires à la mise en place de plugins.

La première chose à faire, c'est de définir un ensemble d'interfaces à nos plugins : ce sont des classes avec seulement des fonctions virtuelles pures utilisées pour dialoguer entre l'application et les plugins. Il est possible bien entendu de définir plusieurs interfaces, pour différents types de plugin, mais dans notre cas nous n'en définissons qu'une seule, OperationInterface :

class OperationInterface
{
public:
    virtual ~OperationInterface() {}
    virtual QStringList operationList() = 0;
    virtualbool canCalculate( QString opName ) = 0;
    virtualint numVariable( QString opName ) = 0;
    virtual QString calculate( QString opName, QStringList variableList ) = 0;
};
Q_DECLARE_INTERFACE(OperationInterface,
                    "org.nikikko.CalcOp.OperationInterface/1.0")

La macro Q_DECLARE_INTERFACE permet d'indiquer lors de la compilation (à l'outil moc, le précompilateur Qt) que cette classe est une interface.

Attention : le deuxième élément de la macro "org.nikikko.CalcOp.OperationInterface" doit obligatoirement se finir par le nom de la classe (je me suis fait avoir au début).

Le reste du code, notamment la classe OperationManager, sera détaillé par la suite.

Création d'un plugin

La création du plugin est relativement simple. Il suffit de créer une classe qui hérite de notre interface OperationInterface. Voici par exemple le code pour le plugin mathématique :

#include <QObject>
#include <operationinterface.h>
class MathPlugin : public QObject, public OperationInterface
{
Q_OBJECT
Q_INTERFACES(OperationInterface)
public:
    QStringList operationList();
    bool canCalculate( QString opName );
    int numVariable( QString opName );
    QString calculate( QString opName, QStringList variableList );
};

Deux remarques importantes :

la classe de base d'un plugin (qui hérite d'une classe d'interface) doit toujours hériter de QObject,
toutes les fonctions de l'interface doivent être définies.

Note : il est possible dans un plugin d'avoir une classe qui hérite de plusieurs interfaces, pour cela voir l'exemple plugandpaint de Qt.

Et dans le fichier source :

Q_EXPORT_PLUGIN2(calcop_math, MathPlugin)

La macro Q_EXPORT_PLUGIN2 indique au compilateur qu'il faut exporter cette classe, et que cette classe est le point d'entrée du plugin. Pour faire simple, une classe exportée est une classe qui est visible à l'extérieur de la bibliothèque (donc par le programme principal).

Enfin, il faut indiquer dans le fichier .pro que l'on souhaite créer un plugin. Voici le fichier .pro correspondant au plugin calcop_math :

  TEMPLATE      = lib
  CONFIG       += release plugin
  INCLUDEPATH  += ../../src
  HEADERS       = mathplugin.h
  SOURCES       = mathplugin.cpp
  TARGET        = calcop_math
  DESTDIR       = ../../bin/plugins

Voilà quelques explications :

TEMPLATE = lib : création d'une bibliothèque
CONFIG += plugin : cette bibliothèque est un plugin
TARGET = calcop_math : ce plugin s'appelle calcop_math (même nom que dans la macro Q_EXPORT_PLUGIN2)
DESTDIR = ../../bin/plugins : mettre ce plugin dans le bon répertoire (répertoire des plugins de l'application)

Voilà, c'est relativement simple à faire, et en plus c'est multi-plateforme.

Chargement des plugins dans l'application

Dernière étape, c'est le chargement des plugins dans l'application. Tout ce qui concerne la gestion des plugins se fait à travers la classe OperationManager dans le programme principal. Cette classe charge les plugins, et s'occupe d'effectuer les appels nécessaires aux fonctions des plugins lors du calcul.

Pour me faciliter la vie, j'ai décidé d'en faire un singleton : c'est pour ça que le constructeur est privé, et que la classe comporte une fonction membre statique instance. Mais le code le plus intéressant se trouve dans le constructeur de cette classe :

QDir pluginsDir = QDir(qApp->applicationDirPath());
    pluginsDir.cd("plugins");
    foreach (QString fileName, pluginsDir.entryList(QDir::Files)) {
        QPluginLoader loader(pluginsDir.absoluteFilePath(fileName));
        QObject *plugin = loader.instance();
        if (plugin) {
            OperationInterface * op = qobject_cast<OperationInterface *>(plugin);
            if (op) {
                m_operationList << op;
            }
        }
    }

Nous avons trois actions importantes dans ce code :

déplacement dans le répertoire de plugin : les deux premières lignes vont nous permettre d'aller dans le répertoire des plugins,
chargement du plugin avec la classe QPluginLoader : on vérifie que le plugin est bien compatible avec la version du logiciel et de Qt, et crée une instance de l'objet racine (qui est une classe héritée de l'interface, dans notre cas ce sera une instance de MathPlugin).
vérification de la compatibilité du plugin : de quelle interface hérite-t-il (ici OperationInterface)

Si tout se passe bien, on enregistre le plugin dans la liste des opérations. Et voilà, c'est simple, clair et propre...

La classe QPluginLoader est au coeur de ce code : c'est elle qui va se charger de créer une instance du plugin. Au passage, l'instance créé, que l'on récupère à l'aide de la fonction instance(), est statique : si l'on utilise le même code dans une autre fonction, l'instance renvoyé sera toujours la même (ie le même pointeur).

Documentation Qtfr - version_Qt4

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

Utilisation de PyQt avec Qt 4.4

Introduction aux MVC et création d'un modèle hiérarchique simple

Présentation

Rétro-conception

simpletreemodel

Description

Exécution

Analyse

Le stockage des données

Le modèle

La méthode parent()

La méthode index()

La méthode data()

La méthode rowCount()

La méthode columnCount()

Les méthodes flags() et headerData()

Conclusion

Notes

Réseau avec Qt4

XML avec Qt4

Dessiner avec Qt4

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

Un conteneur pour MPlayer (utilisation de QProcess)

Généralité sur MPlayer en tant que backend...

Exemple complet

Si vous avez des remarques...

Compiler Qt 4 avec Visual C++ 2005

Qt4 et C++ : Programmation d'interfaces GUI

Informations

Résumé

Table des matières

Intégration de VLC

Introduction

Pré-requis

Lecteur vidéo

Compilation

Linux/Unix

Explications

Initialisation d'un contexte VLC

Ajout d'un flux

Redirection du flux sur un widget Qt

Functions vidéos/audios

Contrôle de la vidéo

Contrôle du volume

Intégration de SDL

Pré requis:

La méthode `parent()`

La méthode `index()`

La méthode `data()`

La méthode `rowCount()`

La méthode `columnCount()`

Les méthodes `flags()` et `headerData()`