Une extension est un fichier chargé par Qt pour apporter de nouvelles fonctionnalités, soit à Qt lui-même, soit à une application. Une extension peut être directement liée à une application (édition statique des liens) ou bien chargée à l'exécution.

Il existe deux API de niveaux différents pour la création d'extensions. Une API de haut niveau, pour les extensions destinés à Qt, et une API de bas niveau pour les applications.

Il existe un ensemble d'extensions réservés à Qt Embedded Linux, autorisant Qt à fonctionner sur une variété de plateformes matérielles différentes et dont les principes d'utilisation sont spécifiques.

Les extensions ne sont pas chargés automatiquement : si Qt a besoin d'une extension pour lire un format d'image qui n'est pas supporté nativement, il demande aux extensions les formats qu'ils peuvent lire. Si l'un d'entre eux semble convenir, il est chargé complètement. Si vous ne lisez pas la moindre image dans votre application, aucune extension de lecture d'images ne sera chargée.

Pendant la compilation de Qt, une buildkey est définie. Elle contient, entre autres, l'architecture (IA32, IA64, AMD64...), l'OS et sa version (Windows 6.0, Linux 2.6...), le compilateur et sa version (GCC 4.4.0, Visual C++ 9.0...), la configuration de Qt (les drapeaux passés lors de la compilation) et une clé optionnelle, spécifiée lors de la compilation (-buildkey).

Pourquoi ? Tous les environnements influencent fortement la manière de produire des binaires. Deux configurations de Qt différentes ne sont pas forcément compatibles. Pour éviter les désagréments éventuels pouvant être causés par des différences de configuration, affectant potentiellement la stabilité du système, Qt vérifie que tous les binaires sont parfaitement compatibles.

Lorsque vous lancez votre application Qt, ce dernier commence par s'initialiser. Il vérifie que la buildkey de votre application correspond à la buildkey de Qt. Ensuite, lors du chargement de chaque module, cette vérification est aussi effectuée. De même lors du chargement de chaque plug-in.

Qt tient un cache avec toutes ces informations. Ce cache est réactualisé à chaque changement d'un des fichiers. Ceci permet d'éviter de recharger la totalité des fichiers à chaque fois, et d'ainsi gagner du temps. Ce cache est géré par QSettings, son emplacement dépend donc de l'OS.

Par exemple, sous Windows, il se situe dans le registre à cet emplacement : HKEY_CURRENT_USER\Software\Trolltech\OrganizationDefaults\.

Il existe certaines conditions sous lesquelles Qt peut tout de même charger des plug-ins pour d'autres versions : que le plug-in ait été compilé avec une version antérieure de Qt, mais de la même branche. S'il a été compilé avec Qt 3, il ne fonctionnera pas avec une application Qt 4. S'il a été compilé avec Qt 4.5.1, et que l'application l'a été avec Qt 4.5.0, le plug-in ne sera pas compatible. Par contre, s'il a été compilé avec la version 4.5.0, et que l'application a été compilée avec Qt 4.5.1, le plug-in sera compatible, à moins qu'une buildkey additionnelle ait été précisée lors de la compilation de Qt : il faudra que le plug-in soit compilé avec une version compatible (donc antérieure) et ait la même buildkey additionnelle.

Qt fournit la classe QLibrary permettant de permettre le chargement d'une bibliothèque dynamique quelle que soit la plateforme utilisée, ainsi que d'en récupérer des pointeurs vers les fonctions exportées.

Après avoir créé un objet de ce type, il faut spécifier le nom de la bibliothèque dynamique à associer sans préciser l'extension, car celle-ci dépend de la plateforme. Il suffit ensuite d'appeler resolve() en fournissant le nom du symbole à trouver. Il est retourné en tant que void*, ce qui implique l'utilisation d'un cast. Sont aussi fournies des fonctions statiques évitant l'instanciation dans le cas où l'on ne voudrait récupérer qu'un symbole.

Par exemple, admettons qu'une fonction d'une bibliothèque permette de compter le nombre de lettres dans un mot.

// définition du type de fonction
typedef int (*StringLength)(char*);
// création d'un objet QLibrary lié à string_util (.dll, .so ou autre)
QLibrary lib("string_util");
// récupération d'un pointeur sur notre fonction partagée
StringLength strLength = (StringLength)lib.resolve("strlen");
if(strLength)
// devrait renvoyer 9... si tout va bien ;)
    strLength("QLibrary");

Toutes les extensions se trouvent dans un répertoire commun, classés selon leur type en autant de sous-répertoires :

• accessible : accessibilité (qui complète un widget) ;
• decorations : style pour Qt Embedded Linux ;
• fontengines : police pour Qt Embedded Linux ;
• iconengines : chargeur d'icônes ;
• imageformats : chargeur d'images ;
• inputmethods : méthode d'entrée (qui convertit des combinaisons de touches en une chaîne de caractères) ;
• kbddrivers : clavier pour Qt Embedded Linux ;
• mousedrivers : souris pour Qt Embedded Linux ;
• pictureformats : ce type de plug-in est déprécié ;
• gfxdrivers : écran pour Qt Embedded Linux ;
• script : extension de Qt Script ;
• sqldrivers : moteur SQL ;
• styles : style ;
• codecs : support d'alphabets non latins.

Avez vous configurer Qt avec le support pour ce type d'image ? Lancez configure avec l'option -help:

./configure -help

pour voir les différentes options de configuration disponible. Vous devez vérifier que le support pour le type d'image a bien été activé et sinon, activez le et recompilez (cela peut nécessiter des dépendances additionnelles).

Si vous exécutez le code suivant, vous pouvez voir les différents types d'images que supporte votre installation de Qt:

#include <qimage.h>
#include <qstringlist.h>
#include <qapplication.h>
 
int main(int, char**)
{
    qDebug("input: %s output: %s",
        QImage::inputFormatList().join(", ").latin1(),
        QImage::outputFormatList().join(", ").latin1());
 
    return 0;
}

Lors de la création de plug-in tiers supportant la gestion des événements, vous allez avoir besoin d'une boucle gérant les événements. Cela peut être fait de trois façons :

1. Vous pouvez instancier la classe QCoreApplication / QApplication et appeler exec() pour démarrer la gestion des événements puis quit() lors de la fermeture du plug-in. En utilisant cette approche, le reste de l'application va être bloqué tant que la boucle de gestion d'événements tournera ;
2. Vous pouvez appeler processEvent(), dans l'application, de manière périodique, avec l'aide des timers pour gérer les événements vous-même. Avec cette approche, le plug-in va toujours se bloquer, mais seulement le temps qu'il n'y ait plus d'événements à gérer. Cela vous permettra de revenir dans l'application principale. De plus, vous avez le contrôle sur le moment où les événements vont être traités ;
3. Vos objets n'ayant pas d'interface graphique peuvent résider dans un thread ayant une boucle d'événements pour éviter les appels à exec()/processEvent() dans l'application principale. La boucle événementielle peut être démarrée en appelant QThread::exec(). Notez que vous avez besoin de créer un objet QApplication (ou QCoreApplication) avant de créer le QThread, mais vous n'avez pas besoin d'appeler exec() à l'aide de ces objets. Vous pouvez trouver plus d'informations sur les boucles d'événements : Boucle d'événements par thread

Seules les classes d'interface utilisateur peuvent être utilisées depuis le thread principal ; le thread pour les événements peut demander des mises à jour de l'interface en envoyant des événements ou des signaux : les signaux et les slots à travers les threads