Documentation Qtfr

Intégrer Ogre dans Qt 4

IrmatDen — Sat, 04 Apr 2009 16:48:00 +0200

Ce tutoriel en 2 parties vous guide pas à pas depuis l'initialisation d'une fenêtre jusqu'au déplacement d'un objet, tout en ajoutant la possibilité d'annuler des actions.

Version : Qt4, Ogre 1.6 (première partie également testée avec la 1.4)
Auteur : Denys Bulant (IrmatDen)

Ce tutoriel est disponible sous la forme de 2 fichiers PDF ; les codes sont téléchargeables directement depuis le pdf et sont hébergés chez developpez.com.

N'hésitez pas à venir en parler sur le fil dédié !

Intégrer Ogre à Qt :

I - Introduction
I-1 - Pourquoi intégrer Ogre à Qt?
I-2 - Pré-requis
II - Initialiser le système
II-1 - Objectif: écran noir (mais grâce à Ogre!)
II-2 - Première interaction: modification de la couleur de fond
III - Affichage d'un objet et gestion de la caméra
III-1 - Ajouter de la lumière et un objet
III-2 - Gérer la caméra (gestion des événements et utilisation d'un dockwidget)
III-2-a - Contrôle du positionnement de la caméra par des spinbox
III-2-b - Contrôle du positionnement de la caméra par le clavier
III-2-c - Contrôle du positionnement de la caméra par la souris
IV - Sélection d'entité
V - Conclusion
VI - Remerciements

Intégrer Ogre à Qt - Partie 2 :

I - Une autre gestion des événements
I-1 - Inconvénients de l'approche précédente et motif pour changer
I-2 - Implémentation
I-2-1 - Définition de l'interface nécessaire et modification au code actuel
I-2-2 - Implémentation du déplacement de la caméra
I-2-3 - Implémentation du déplacement de l'objet sélectionné
II - Support de l'annulation
II-1 - Présentation du framework Undo fourni par Qt
II-2 - Implémentation
II-2-1 - Préparatif
II-2-2 - Annulation du changement de couleur de fond
II-2-3 - Annulation du déplacement d'un objet
III - Conclusion

Le tutoriel de Qt 4.5 est maintenant disponible en français

Nicolas — Fri, 13 Feb 2009 15:37:00 +0100

-d'après A French tutorial for “Mignon 4.5″-

Après le site de Qt Software (qui est partiellement traduit, les pages importantes on va dire), voilà maintenant le tutorial de Qt qui est traduit dans la langue de Molière. Pour ceux que ça intéresse, vous le retrouverez sur cette page.

Merci à tous ceux impliqués dans cette traduction, ça va aider certains qui ne s'y retrouvaient pas avec la langue de Shakespeare, et nous permettre de donner un lien dans le forum pour les débutants.

Utiliser la version de développement de WebKit avec Qt 4.4

Red Rabbit — Thu, 05 Jun 2008 16:46:00 +0200

Une astuce pour utiliser la branche principale de développement du projet WebKit au lieu de la version livrée avec Qt.

Version : Qt4/version de développement de WebKit
Auteur : Red Rabbit

Vous aurez besoin de la version 4.4.x de Qt pour suivre ce tutoriel

Introduction

Dans sa dernière version, Qt s'est vu monté d'un nouveau module: QtWebKit, un moteur de rendu HTML concurrençant Gecko (Firefox), Presto (Opera) et Trident (IE).
Le projet WebKit étant en constant développement, il est dommage de devoir en utiliser une version obsolète avec Qt.

Heureusement pour nous, le portage de Webkit vers les interfaces graphiques Qt et Gtk+ est développé dans la branche principale. Ce qui signifie que QtWebKit est en évolution continue.
Donc pourquoi laisser passer une telle opportunité ?

Télécharger les sources de WebKit

Nous allons donc télécharger les sources à l'aide d'un système de gestion de versions.

Avec Subversion:
$ svn co http://svn.webkit.org/repository/webkit/trunk WebKit

Avec Git:
$ git clone git://code.staikos.net/webkit

Compiler les sources

Comme un bon lien vaut mieux qu'un long discours, je vous prie de suivre les étapes se trouvant sur la documentation officielle.

Configurer mon projet

La compilation maintenant terminée, il faut indiquer à Qt d'utiliser notre nouvelle version de QtWebKit plutôt que celle livrée par défaut.

Téléchargez le fichier webkittrunk.pri et placez le à cotez de votre fichier .pro.
C'est le contenu de ce fichier qui permet à Qt d'utiliser une version de QtWebKit autre que la sienne (pensez à changer le chemin WEBKITHOME dans le fichier webkittrunk.pri).

Pour que Qt prenne en compte les changements lors de la compilation du projet, ajoutez la ligne suivante à votre fichier .pro:
include( webkittrunk.pri )

Pour finir, il faut définir la variable globale QT_WEBKIT=webkit_trunk pour indiquer à Qt d'utiliser notre version de QtWebKit et voilà le tour est joué.

Votre projet utilise désormais la version actuelle de WebKit, elle est pas belle la vie !?

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.

Intégration de Qt 4 Open Source avec Apple Xcode 3.0 et 3.1

chsxf — Wed, 12 Mar 2008 10:03:00 +0100

Qt est un toolkit fabuleux disposant de kits d'intégration pour divers IDE dans sa version commerciale mais quasiment aucun pour sa version Open Source. Ce tutoriel cherche à vous faciliter l'intégration de Qt avec Apple Xcode pour Mac OS X.

Version : Qt4 / Xcode 3.0 ou 3.1
Auteur : Christophe (chsxf)

Ce tutoriel requiert l’installation de Qt 4 pour Mac OS X bien que cette étape sorte du cadre de cet exposé.

Les fichiers projets Qt

Afin de conserver une portabilité maximale au travers de systèmes aussi hétéroclites que Windows, Mac OS X ou Linux, Qt propose un ensemble d’outils de gestion des projets. La base de cet ensemble est représentée par un fichier se terminant par l’extension .pro (pour projet) et l’utilitaire qmake. Le principe est simple : la configuration du projet s’effectue au sein du fichier .pro et l’utilitaire qmake se charge de générer les scripts de compilation adéquats en fonction de la plate-forme (notamment la création des fameux Makefile).

Ce principe de fonctionnement est très spécifique à Qt et des environnements de développements intégrés (IDE) comme Xcode ne sont pas conçus pour le supporter dès leur mise en route. Il existe toutefois des solutions pour contourner une partie des écueils que l’on peut rencontrer dans ce cas précis en acceptant de faire une croix sur certaines facilités.

Projet Xcode ou projet Makefile ?

Deux approches sont à considérer en débutant un développement Qt sous Xcode. Faut-il choisir de travailler uniquement à partir des projets natifs Xcode (fichiers .xcodeproj) ou d’envisager un projet à base d’un fichier .pro et de Makefiles ?

Autant vous le dire immédiatement, la première solution n’offre que peu d’avantages puisque créer un fichier de projet Xcode pour gérer la totalité de votre développement ne permet pas de prendre en charge l’actualisation du contenu de votre fichier .pro lors de l’ajout de classes ou de boîtes de dialogues. Les fichiers .pro constituant la base d’un projet Qt, il vous serait alors impossible de transposer de façon immédiate vos fichiers sources depuis votre Mac vers n’importe quel autre système ou, plus ennuyeux, environnement de développement. C’est pourquoi nous choisirons la deuxième approche.

Configurer un projet Makefile

Ce que nous appelons un « projet Makefile » est tout simplement une méthode détournée qui permet de configurer Xcode (ou n’importe quel autre IDE qui l’autorise) pour qu’il utilise un système de configuration à base de fichiers Makefile. L’intérêt dans le cas de Qt est que les fichiers .pro et qmake fonctionnent à merveille avec cette solution, de façon portable.

Nous ensivagerons les étapes de façon différente pour Xcode 3.0 ou Xcode 3.1 (en version béta à l’heure ou nous écrivons ces lignes) le cas échéant.

Pour commencer

La première étape consiste à créer un projet adapté :

Xcode 3.0

Créez un nouveau projet par le menu File > New project…
Sélectionnez le type External Build System (Système de Compilation Externe)
Après avoir sélectionné l’emplacement du projet, Xcode vous fournit un projet vide prêt pour compiler un fichier Makefile.

Xcode 3.1 (avant la beta 3 du SDK iPhone)

Créez un nouveau projet par le menu File > New project…
Sélectionnez le type de projet que vous souhaitez et nommez-le.
Dans la fenêtre de projet, supprimez toutes les entrées et les dossiers appartenant au projet.
Dans la section Targets, supprimez la cible par défaut.

Xcode 3.1 (après la beta 3 du SDK iPhone)

Créez un nouveau projet par le menu File > New project…
Sélectionnez le type External Build System (Système de Compilation Externe) dans la section Others (Autres)
Après avoir sélectionné l’emplacement du projet, Xcode vous fournit un projet vide prêt pour compiler un fichier Makefile.

Préparer l'exécution de qmake

La deuxième étape consiste à préparer les cibles pour exécuter qmake puis compiler les Makefiles générés :

Xcode 3.0

Avec cette version d’Xcode, vous disposez déjà d’une cible permettant l’appel de make et la compilation des Makefiles. Il ne vous reste plus qu’à ajouter la cible propre à qmake.
Rendez-vous dans le menu Project > New target…
Sélectionnez le type External Target (Cible externe).
Nommez la cible qmake et terminez. La cible doit apparaître dans la section Targets de votre projet.
Double-cliquez cette nouvelle cible pour faire apparaître ses propriétés.
Dans le champ Build Tool, entrez /usr/bin/qmake
Dans le champ Arguments, supprimez le texte existant et entrez –spec macx-g++
Fermez la fenêtre.

Xcode 3.1

Rendez-vous dans le menu Project > New target…
Sélectionnez le type External Target (Cible externe) dans la section Others.
Nommez la cible make et terminez. La cible doit apparaître dans la section Targets de votre projet.
Une deuxième fois, rendez-vous dans le menu Project > New target…
Sélectionnez le type External Target (Cible externe).
Nommez la cible qmake et terminez. La cible doit apparaître dans la section Targets de votre projet.
Double-cliquez cette nouvelle cible pour faire apparaître ses propriétés.
Dans le champ Build Tool, entrez /usr/bin/qmake
Dans le champ Arguments, supprimez le texte existant et entrez –spec macx-g++
Fermez la fenêtre.

Terminé !

Il ne nous reste plus qu’à déterminer les dépendances entre les cibles. Sélectionnez la cible qmake et glissez-la sur l’autre cible de votre projet pour que cette dernière en devienne dépendante. Si la dépendance a été validée, la cible qmake devrait apparaître comme un enfant de la première cible (cliquez éventuellement sur la flèche correspondante pour déplier la branche relative à la cible). Les dépendances ont une signification simple. Toute cible qui dépend d’une autre exécutera la cible dont elle dépend avec elle-même. Dans le cas présent, nous demandons à ce que la cible active exécute la cible qmake pour générer les fichiers Makefiles à partir des données du projet avant de vouloir lancer la compilation avec make.

Fichiers .pro et début du développement

La dernière étape consiste à insérer dans le projet Xcode les éléments de votre projet Qt. Nous supposons que vos fichiers Qt se trouvent dans le même répertoire que le fichier .xcodeproj. Il vous suffit alors de les ajouter au projet Xcode. Pour ce faire, utilisez le menu Project > Add to Project… et sélectionnez votre fichier .pro, vos fichiers sources et éventuellement les autres fichiers susceptibles d’en faire partie (ressources, fichiers QtDesigner, etc…).

Compilation

A ce stade, votre projet devrait être prêt à compiler. C’est l’heure de vérité. Tentez le menu Build > Build et contrôler le résultat dans la barre d’état d’Xcode ou dans la fenêtre Build > Build Results.

Lancement de l’exécutable

Il est temps maintenant d’exécuter votre logiciel. Utilisant un système de compilation externe, Xcode n’est pas en mesure de connaître de façon automatique l’emplacement de votre exécutable. Vous allez devoir l’ajouter au projet. Utilisez le menu Project > New Custom Executable… (Nouvel exécutable personnalisé) et sélectionnez le fichier de l’exécutable. Il devrait apparaître dans la section Executables du projet. En tant qu’unique exécutable du projet, il devient également l’exécutable actif et sera exécuté par défaut à chaque fois que vous souhaiterez exécuter votre projet.

Utilisez le menu Run > Run ou Run > Go pour le lancer.

Avantages et Défauts

Le terme Défauts est au pluriel dans ce titre mais la méthode exposée précédemment n’en présente qu’un seul : le fichier .pro n’est pas actualisé automatiquement en cas de nouveaux ajouts de fichiers à votre projet.

Certes, il s’agit là d’un manque à combler dans l’intégration de Qt à Xcode mais en comparaison des nombreux avantages que présente notre méthode, cela n’est pas grand chose :

Respect du standard instauré par Qt pour la compilation des projets
Portabilité du fichier .pro d’une plate-forme à une autre
Aucune contrainte au moment du passage à un autre IDE qu’Xcode
Possibilité de modifier le projet Qt en dehors d’Xcode sans avoir à reconfigurer Xcode

Conclusion

Comme toute chose, Xcode possède ses amateurs et ses détracteurs. En tant que produit Apple, il constitue un incontournable pour le développement d’applications natives Mac OS X. Bien que des environnements de développements portables spécifiques à Qt existent tels que MonkeyStudio, Edyuk ou encore QDevelop, les utilisateurs d’Xcode trouveront peut-être un intérêt à éviter la multiplication des outils et nous espérons que ce tutoriel les aura aidé à améliorer leur entrée dans le monde de Qt.

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().

Initiation à Qt Jambi

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

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

Version : Jambi
Auteur : Natim

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

L'utilisateur découvrira:

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

Rapid GUI Programming with Python and Qt

Visiteur — Sun, 25 Nov 2007 15:27:00 +0100

Mark Summerfield déjà co-auteur du célèbre livre C++ GUI Programming with Qt 4 (traduit en Français aux éditions Pearson Education) nous livre un nouvel opus sur la librairie Qt4 mais dédié cette fois-ci au language Python.

Merci à tool69 pour cette revue, qui donne envie de se plonger dans la lecture de cet ouvrage.

Auteur : tool69

Informations

Auteurs : Mark Summerfield
Editeur : Prentice Hall PTR
Langue : anglais
ISBN : 0132354187
Pages : 460
Public visé : tout développeur Python, même débutant
Page du livre : http://www.qtrac.eu/pyqtbook.html

Résumé et revue

Parlons de la qualité du livre lui-même : une belle couverture rigide sur laquelle figure l'image du satellite Hubble en orbite autour de la Terre. Le sens ? Python est utilisé par la NASA pour calibrer et analyser les données recueillies par celui-ci. Que ce soit le papier, la qualité d'impression ou les multiples diagrammes, il n'y a rien à redire si ce n'est qu'on aimerait voir ce genre d'initiatives plus souvent chez nos éditeurs, surtout eû égard au prix pratiqué.

Passons maintenant au contenu proprement dit, qui se divise en quatre parties distinctes (cinq en fait si l'on compte les divers appendices qui représentent à eux seuls presque une centaine de pages) :

Programmation avec Python;
Programmation d'interfaces graphiques niveau basique;
Programmation d'interfaces graphiques niveau intermédiaire;
Programmation d'interfaces graphiques niveau avancé;

On peut s'interroger sur le bien fondé de la première partie, en effet il serait étonnant qu'une personne ne connaissant pas le language se risque à acheter un tel livre. Et pourtant Mark réussi là un véritable tour de force : on balaye les fonctionnalités du language par la pratique, avec des exemples vraiment très pertinents. J'avoue même avoir appris certains concepts dont je ne soupçonnais pas l'existence, sans doute faute d'en avoir eû un réel besoin. Les fonctions partielles par exemple ont un intérêt certain dans la suite de l'ouvrage. De la même façon, vous pourrez y voir de multiples références au PEPs (Python Enhancement Proposals : les fonctionnalités à venir de Python).

Si l'anglais peut rebuter au départ, surtout lorsqu'il est technique, on se surprend rapidement à lire un thème donné sans avoir recours au dictionnaire (je précise que je n'ai aucune thèse en anglais). Le style se veut simple et efficace, sans être simpliste.

Autant vous rassurer tout de suite, le contenu des trois parties consacrées au vif du sujet, la programmation d'interfaces graphiques n'est pas du tout un plagiat du livre précédent : C++ GUI Programming with Qt 4. On y aborde évidemment plus ou moins les mêmes sujets, mais un réel travail a été fourni sur les nouvelles fonctionnalités apparues depuis la version 4.2 de Qt4. Citons par exemple un chapitre entier consacré à l'architecture du Graphics view : un réel plus par rapport au livre précédent.

Les exemples sont abondants, collent à la pratique et vous pourrez en outre les récupérez gratuitement sur la page que Marc à consacré à son ouvrage. Sachez du reste qu'elle est remise à jour régulièrement, afin d'améliorer encore certains exemples et de proposer un errata.

Citons aussi quelques petits cadeaux vraiment bien venus : des utilitaires écrits par l'auteur afin de gérer au mieux vos projets PyQt4.

A chaque fois, on vous place en situation de développeur et vous serez amené à résoudre quelques exercices proposés en fin de chapitre.

J'ai beaucoup apprécié l'éventail d'alternatives à un problème donné. Comment imprimer le contenu d'un QTextEdit par exemple ? Marc vous propose trois méthodes abondamment commentées, de la plus simple à la plus complexe, à vous de choisir ensuite en fonction de vos besoins, de votre niveau ou du temps que vous allez y passer.

Vous l'aurez donc compris, j'ai été plus que séduit par ce livre. On ne passe pas son temps à comparer Qt à tel autre toolkit comme le font certains ouvrages (d'ailleurs, serait-ce vraiment la peine ?), on pratique avant tout, et les repères ne manquent pas: index abondant, diagrammes de classes, éventail visuel de tous les widgets.

Des critiques ? Un chapitre de C++ GUI Programming with Qt 4 était consacré au développement de plugins avec C++, il est absent ici, comme dans tout livre sur Python consacré à ce vaste sujet. Il est vrai que les possibilités dynamiques qu'offrent Python permettent de pallier à ce problème assez facilement, mais encore faut-il mettre la main à la pâte. S'il est absent, c'est à mon avis surtout parce qu'il n'existe pas de recette toute faite, mais j'aurais au moins aimé disséquer un exemple simple sur le sujet.

Enfin contrairement à beaucoup d'autres ouvrages, Rapid GUI Programming with Python and Qt se distingue aussi par la façon dont il a été écrit. Pas de LaTeX, de Scribus, de QuarkXPress ni même de InDesign ici, mais une alternative originale et légère : Lout.

Au secours, mes slots ne fonctionnent pas

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

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

Version : Qt3, Qt4
Auteur : Ludo (lud42fr)

Don't panic

Premier diagnostic:

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

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

Premiers réflexes:

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

L'action au ralenti

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

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

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

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

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

class maClasse : public QObject
   {
    Q_OBJECT
    public:
   };

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

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

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

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

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

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

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

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

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

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

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

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

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

Et on met encore moins de valeurs

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

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

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

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

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

Ca ne marche toujours pas :

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

Annexes

Activer la console

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

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

CONFIG += console

puis recompiler l'application.

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

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

Environnement de développement pour Greenphone

Nicolas — Fri, 27 Apr 2007 22:34:00 +0200

Comment développer une application pour Greenphone ?
Comment installer l'environnement de développement pour Greenphone ?
Comment se lancer dans la programmation pour Greenphone ?

Cet article va nous permettre d'installer un environnement de programmation afin d'écrire des programmes pour le Greenphone. Il faut savoir qu'il est tout à fait possible de développer une application sans avoir un Greenphone.

L'installation et l'utilisation de cette environnement va vous permettre de tester vos applications pour Greenphone sans avoir à les transférer sur un Greenphone, et même de pouvoir tester l'envoie de SMS et de MMS.

Version : Qtopia4 (SDK pour Greenphone)
Auteur : Nicolas Arnaud-Cormos (nikikko)

Installation

L'installation en elle-même est relativement simple, tout l'environnement de développement est disponible sur une image vmware : l'environnement est exécuté dans une machine virtuelle.

Il est par contre nécessaire d'installer le logiciel VMWare player, qui est gratuit est disponible sur le site de VMware ou sur certaines distributions Linux.

ISO de la SDK

L'image vmware n'est pas disponible directement en téléchargement, il faut récupérer une image ISO et la graver pour pouvoir effectuer l'installation.

télécharger l'image ISO sur le site de Qtopia : page de téléchargement, choisissez la dernière disponible (actuellement : Greenphone Community SDK 4.2.1),
graver l'image sur un CD.

Note : la documentation est disponible sur le CD, sous le forme de fichier PDF (notamment greenphone_quickstart.pdf).

Installation de l'image vmware

L'image vmware est installable à partir du CD que vous venez de graver.

Sous Windows

Normalement, le programme d'installation se lance automatiquement. Si ce n'est pas le cas, allez sur le CD et lancer l'exécutable autorun.exe.

suivre les indications de l'installeur... normalement, pas de problème à cette étape.

Sous Linux

aller sur le cdrom : cd /mnt/cdrom ou cd /media/cdrom
lancer l'installation de l'image : sh install.sh, et suiver les instructions de l'installeur
lancer l'image vmware en allant de le répertoire d'installation avec la commande suivante :

 vmware greenphone.vmx

Environnement de développement

Ca y est, vous avez installer l'environnement de développement ! Bravo ! Une fois lancé, vous avez un bureau KDE/Linux en 1024x768 (pour la petite histoire, c'est une Debian Etch personnalisée) :

Je vais maintenant détailler quelques personnalisation qui me semblent être indispensable pour développer correctement.

Utilisateurs

Deux utilisateurs sont prédéfinis :

user (mot de passe user) : l'utilisateur sous lequel vous êtes connecté
root (mot de passe root) : l'administrateur

Configuration du clavier

Première chose à faire, changer la configuration du clavier pour ceux qui ont un clavier azerty (vous l'avez peut-être remarqué, mais c'est configuré pour un clavier qwerty) :

aller dans le menu K (en bas à gauche) > Settings > Control Center
aller dans Regional & Accessibility > Keyboard Layout
modifier comme indiqué dans la capture d'écran suivante :

Modification de la résolution

Je ne sais pas vous, mais moi j'ai la chance de ne pas avoir un écran 1024x768... il est donc nécessaire de modifier la résolution :

ouvrir une console (icône Konsole) et taper les commandes suivantes (la deuxième commande va demander le mot de passe de l'utilisateur root) :

cd /etc/X11
sudo nano xorg.conf

modifier dans la section "Screen" la taille :

    Subsection "Display"
        Depth       24
        Modes       "1024x768"
        ViewPort    0 0
    EndSubsection

redémarrer l'image vmware pour prendre les modifications en compte

Installation de Subversion

Personnellement, je vois mal un environnement de développement sans un gestionnaire de versions, j'ai donc installer Subversion. Pour cela, ouvrez une console et tapez les lignes suivantes :

sudo apt-get update
sudo apt-get install subversion

La première ligne entraîne des erreurs chez moi, mais ce n'est pas grave, l'installation se passe bien au final.

Exécution du programme d'exemple

Afin de vérifier le bon fonctionnement, nous allons compiler et exécuter un programme d'exemple (qui est fourni dans le SDK) :

ouvrir une console (cliquez sur l'icône de la console)
rentrer les commandes suivantes :

source /opt/Qtopia/SDK/scripts/devel-x86.sh
cd ~/projects/application
qtopiamake
make clean
make
make install
gph -rescan

Note : lors de l'exécution de la dernière ligne, j'ai chez moi plusieurs erreurs (QWSSocket::connectToLocalFile could not connect:: Connection refuse), mais ça ne semble pas gêner l'exécution du programme)

cliquer sur l'icône runqpe pour lancer Qtopia dans Qvfb avec le skin Greenphone
naviguer dans le menu (Applications->Example) ou taper ./example dans la console pour lancer l'exemple

Amusez-vous bien avec le Greenphone !

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;
};

Cross Compilation Native d'application Qt depuis Linux/Unix Like

P@sNox — Sat, 14 Apr 2007 10:01:00 +0200

Qu'est ce que la cross compilation ?
Comment créer un executable pour une architecture différente ?
Comment créer un exécutable Windows sous Linux ?

Un compilateur croisé (en anglais cross compiler.) est un programme capable de traduire un code source en code objet ayant un environnement d'exécution (architecture matérielle, système d'exploitation) différent de celui où la compilation est effectuée. Ces compilateurs sont principalement utilisés en informatique industrielle.

Cet article va detailler la mise en place et l'utilisation d'un environnement de compilation multi plateforme. En effet, tout le monde n'a pas Windows dans sa poche ( et heureusement :D ), et fournir un executable pour une architecture autre que la sienne peut parfois etre un vrai calvaire.
Aussi à travers de ce tutoriel, nous allons mettre un place un tel systeme en utilisant mingw32 et Qt4.

Version : Qt4 (supérieur ou égal à Qt 4.0, peut etre valable pour n'importe quelle autre librairie)
Auteur : Filipe Azevedo (pasnox)
Test : Kubuntu Feisty 7.04 beta (Qt 4.2.3)

Pré-requis

Le but de ce tutoriel est de montrer comment compiler une application Qt 4 pour Windows depuis Linux. Nous aurons donc besoin d'installer les logiciels suivant :

mingw32 (disponible normalement dans les paquets de votre distribution, il aura pour effet d'installer en plus les paquets suivant : mingw32-binutils et mingw32-runtime)
Wine (pour ensuite tester votre application Windows sous Linux)
Une installation correcte de Qt 4 pour Windows version mingw
Une installation correcte de Qt 4 pour Linux

Installation des paquets (système basé sur debian)

La façon la plus simple d'installer mingw32 et Wine est d'ouvrir une console (ou bien un gestionnaire de paquet, tel Adept) et d'y inscrire les commandes suivante :

pasnox@pasnox-desktop:~$ sudo apt-get install mingw32
pasnox@pasnox-desktop:~$ sudo apt-get install wine

Note : les commandes d'installation de paquet ci contre ne sont valables que pour debian/ubuntu/kubuntu, ou tout systeme basé sur debian, veuillez vous réferrer à la documentation de votre distribution linux le cas échéant.

Installation de Qt 4 Windows

Maintenant que nous avons installé Wine, nous pouvons installer la version Windows de Qt 4 qui utilise mingw (par exemple la version 4.2.3) Une fois téléchargé, pour l'installer, veuillez ouvrir une console et taper :

pasnox@pasnox-desktop:~$ wine chemin/de/qt/pour/windows/qt-win-opensource-4.2.3-mingw.exe

Je vous conseille d'installer la librairie Qt dans un dossier dont le chemin ne contient pas d'espace, par exemple : C:\Development\Qt\4.2.3 (chemin qui sera utilisé par la suite).

Attention : il n'est pas nécessaire d'installer mingw depuis l'installateur, même si celui-ci vous dit qu'il ne le trouve pas.

Configuration de Wine

Maintenant que Qt 4 pour Windows est installé, il faut indiquer à Wine où trouver les librairies Qt. Il s'agit en fait de modifier la base de registres, car les variables d'environnement ne sont pas accessibles. Pour ce faire, exécuter le logiciel Wine RegEdit.

pasnox@pasnox-desktop:~$ wine regedit

Rendez-vous dans la clé HKEY_CURRENT_USER. Si la clé Environment n'existe pas, veuillez la créer en faisant clique droit sur la clé HKEY_CURRENT_USER, puis nouvelle clé.
Dans cette clé ( Environment ), la valeur nommé PATH devrait s'y trouver . Si celle-ci n'existe pas créez là : clique droit sur la clé Environment puis nouvelle valeur chaine.
Nommez-la PATH et donnez lui la valeur du chemin d'installation des exécutables de Qt, c'est à dire C:\Development\Qt\4.2.3\bin.

Parfait, il manque maintenant une dll, celle-ci se nomme mingwm10.dll et est disponible depuis les paquets installés. Pour ne pas être embêté, nous allons la copier dans le dossier system32 de Wine, ce qui permettra d'executer des applications mingw depuis Wine plus facilement.

Ouvrez une console et tapez :

pasnox@pasnox-desktop:~$ gunzip -c /usr/share/doc/mingw32-runtime/mingwm10.dll.gz > ~/.wine/drive_c/windows/system32/mingwm10.dll

Vous disposez maintenant d'une version de Wine prête pour l'exécution d'application Qt 4.

Création d'un mkspec

Pour pouvoir compiler notre application, il va nous falloir créer un nouveau mkspec basé sur celui de win32-g++. Copiez donc le contenu grâce à la commande suivante (/usr/share/qt4 est le répertoire d'installation par défaut des paquets Qt4 sous distribution à base de Debian) :

pasnox@pasnox-desktop:~$ sudo cp -r /usr/share/qt4/mkspecs/win32-g++ /usr/share/qt4/mkspecs/win32-x-g++

On a donc maintenant un nouveau mkspec nommé win32-x-g++ basé sur win32-g++. Il faut remplacer quelques variables contenues dans le fichier qmake.conf de ce nouveau mkspec, toujours dans la console tapez :

pasnox@pasnox-desktop:~$ sudo kate /usr/share/qt4/mkspecs/win32-x-g++/qmake.conf

Note : Vous pouvez utiliser autre chose que kate comme éditeur de texte.

Les variables à remplacer sont en fait les compilateurs C et C++ ( gcc et g++ ) ainsi que les commandes DOS.

Voici les variables a modifier :

QMAKE_CC		= i586-mingw32msvc-gcc
QMAKE_CXX		= i586-mingw32msvc-g++
QMAKE_INCDIR		= /usr/i586-mingw32msvc/include
QMAKE_INCDIR_QT		= ~/.wine/drive_c/Development/Qt/4.2.3/include
QMAKE_LIBDIR_QT		= ~/.wine/drive_c/Development/Qt/4.2.3/lib
QMAKE_LINK		= i586-mingw32msvc-g++
# N'oubliez pas le -mwindows a la fin pour éviter d'avoir une console dans vos applications
QMAKE_LFLAGS		= -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -mwindows
# les commande DOS sont à remplacer par les commandes shell unix
#isEqual(MINGW_IN_SHELL, 1) {
	QMAKE_DIR_SEP		= /
	QMAKE_COPY		= cp
	QMAKE_COPY_DIR		= cp -r
	QMAKE_MOVE		= mv
	QMAKE_DEL_FILE		= rm -f
	QMAKE_MKDIR		= mkdir -p
	QMAKE_DEL_DIR		= rm -rf
#} else {
# Vous pouvez effacer la partie else qui ne sert a rien, ainsi que le isEqual du dessus
#}
# Enlever les .exe des executables
QMAKE_MOC               = $$[QT_INSTALL_BINS]$${DIR_SEPARATOR}moc
QMAKE_UIC               = $$[QT_INSTALL_BINS]$${DIR_SEPARATOR}uic
QMAKE_IDC               = $$[QT_INSTALL_BINS]$${DIR_SEPARATOR}idc
QMAKE_RCC               = $$[QT_INSTALL_BINS]$${DIR_SEPARATOR}rcc
QMAKE_LIB		= i586-mingw32-ar -ru
QMAKE_RC                = i586-mingw32msvc-windres
QMAKE_STRIP             = i586-mingw32msvc-strip

Une fois terminée, vous êtes enfin prêt à compiler votre application pour windows :)

Pour ce faire vous utiliserez le mkspec win32-x-g++ lors de l'apelle à qmake :

pasnox@pasnox-desktop:~$ qmake-qt4 -spec win32-x-g++ && make

Note : Il semblerait que sous mac, il faille ajouter la platforme à la ligne de commande qmake : -win32

Une fois compilée, l'application se trouve dans le dossier release en cas de compilation release, ou bien dans le dossier debug ( vous aurez besoin de compiler Qt en debug pour cela )

Pour lancer l'application grace à Wine :

pasnox@pasnox-desktop:~$ wine release/mon_application.exe

Il est à noter que le binaire aura besoin, tout comme une compilation via mingw32 sous Windows, des dll Qt (au minimum de QtCore pour une application console, et QtCore/QtGui pour une application graphique simple) ainsi que de mingwm10.dll.

Note : Pour supprimer la dépendance aux dlls de Qt, il est nécessaire de compiler Qt4 Windows en version statique, mais c'est un problème qui n'est pas traité ici... peut-être plus tard.

Bonne cross compilation !

Autres sources

Vous trouverez ici d'autres informations sur la cross-compilation ici :

Cross-compilation C++/QT4 sur le forum, par Amalsek,
Cross-compilation vers un environnement Win32,
Cross compiling Qt/Win Apps on Linux.

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.

Utilisation du designer avec PyQt4

Visiteur — Fri, 30 Mar 2007 21:03:00 +0200

Comment utiliser le designer avec PyQt4 ?
Comment intégrer les widgets créer avec le designer dans un programme python ?

Cet article va détailler l'intégration d'un widget créer avec le designer Qt dans un programme python, en utilisant le binding python de PyQt de Riverbank. Il va aussi détailler l'utilisation de pyuic, qui permet de générer le code python à partir des fichiers créés par le designer.

Auteur : Kib² (tool69)
Version : PyQt4 (Riverbank)

L'article est disponible sur le site de Kib² : http://kib2.webfactional.com/blog/2....

Si jamais vous avez déjà programmé en Python avec la bibliothèque d'origine TkInter, vous savez déjà que coder une interface utilisateur à la main est une tâche à la fois longue et fastidieuse.

QtDesigner est l'outil fourni par la bibliothèque Qt qui vous permet de réaliser une GUI (en Français une IHM : Interface Homme-Machine), par le biais d'un système de glisser-déposer. Il est ainsi possible de créer trois types de « formes » : des widgets, des dialogues ou des applications, tout ceci vous étant demandé par QtDesigner lors de création d'une nouvelle « form » (à partir du menu, choisir File/New Form).

QtDesigner ne génère pas de code source directement. Il peut uniquement sauvegarder votre « forme » avec l'extension « .ui », un dérivé du format XML. Il vous est alors possible, grâce à un module nommé « uic » (lui même écrit en Python) de générer le code Python à l'interface que vous avez précédemment déssiné. C'est à la fois un gain de temps et de productivité, mais aussi une bonne façon de séparer le fond de la forme de votre interface.

C'est l'utilitaire en ligne de commande nommé « pyuic4 » qui vous permettra de manipuler le module « uic », il sera détaillé un peu plus loin.

Il est aussi disponible en libre téléchargement en annexe au format PDF et html.

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...

Documentation Qtfr

Intégrer Ogre dans Qt 4

Le tutoriel de Qt 4.5 est maintenant disponible en français

Utiliser la version de développement de WebKit avec Qt 4.4

Introduction

Télécharger les sources de WebKit

Compiler les sources

Configurer mon projet

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

Intégration de Qt 4 Open Source avec Apple Xcode 3.0 et 3.1

Les fichiers projets Qt

Projet Xcode ou projet Makefile ?

Configurer un projet Makefile

Pour commencer

Préparer l'exécution de qmake

Terminé !

Fichiers .pro et début du développement

Compilation

Lancement de l’exécutable

Avantages et Défauts

Conclusion

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

Initiation à Qt Jambi

Rapid GUI Programming with Python and Qt

Informations

Résumé et revue

Au secours, mes slots ne fonctionnent pas

Don't panic

Premier diagnostic:

Premiers réflexes:

L'action au ralenti

Ca ne marche toujours pas :

Annexes

Activer la console

Réseau avec Qt4

XML avec Qt4

Environnement de développement pour Greenphone

Installation

ISO de la SDK

Installation de l'image vmware

Sous Windows

Sous Linux

Environnement de développement

Utilisateurs

Configuration du clavier

Modification de la résolution

Installation de Subversion

Exécution du programme d'exemple

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

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()`