Documentation Qtfr - Documentation

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.

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

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)

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

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.