Sortie de Qt Creator 4.1

Qt Creator 4.1 vient de sortir. Cette version mineure apporte pas mal d’améliorations incrémentales à l’EDI, sans le révolutionner. Notamment, deux nouveaux thèmes ont été ajoutés (l’un foncé, l’autre clair), ainsi que deux nouveaux jeux de couleurs pour la coloration syntaxique (basés sur la palette Solarized).


Au niveau fonctionnel, les éditeurs de texte gèrent nettement mieux l’insertion et le saut de caractères : en tapant un guillemet, une parenthèse, un crochet ou une accolade ouvrant, le caractère fermant est automatiquement inséré juste après ; si l’utilisateur supprime le premier caractère, celui que Qt Creator a ajouté est supprimé ; si on tape le caractère fermant quand le curseur est à son niveau, cette frappe remplace le caractère inséré. Cependant, ces comportements (attendus par bon nombre d’utilisateurs habitués à d’autres outils) peuvent être configurés.

Le modèle de code Clang et l’analyseur statique associé utilisent maintenant une version bien plus récente de la bibliothèque-compilateur, la 3.8.1, qui résout bon nombre de défauts. Les problèmes entre Clang et Visual C++, détectés lors de la publication de la RC 1, ont été résolus.

Une autre nouveauté, probablement moins attendue, est une extension pour le langage Nim : elle contient la coloration syntaxique, l’indentation, les styles de code. Il est aussi possible de compiler, de lancer et de déboguer des applications Nim.

Voir aussi : la liste des changements complète.
Télécharger Qt Creator 4.1.0.
Source : Qt Creator 4.1.0 released.
Merci à Claude Leloup pour ses corrections.

Kirigami : KDE présente ses extensions aux Qt Quick Controls

KDE est, historiquement, le premier utilisateur dans le monde du libre de Qt. Cet environnement de bureau pour Linux (et autres) s’est construit exclusivement sur la bibliothèque pour son interface graphique. Au fil des années, pour éviter la duplication de code entre les diverses applications, certains composants ont été rassemblés dans des bibliothèques d’extension de Qt, d’abord nommées kdelibs (prévues exclusivement pour KDE), puis récemment transformées en KDE Frameworks dès KDE 5 : les développeurs ont voulu faciliter la réutilisation de composants développés pour KDE dans des applications Qt tout à fait découplées de KDE.

Qt Quick prend de plus en plus d’ampleur côté KDE, notamment pour le développement des plasmoïdes (de petites applications, affichées au niveau du bureau de KDE), mais également pour les applications Plasma Mobile (KDE sur téléphone portable). Pour faciliter ces développements, il a donc été décidé de créer une bibliothèque qui rassemble bon nombre de composants utiles, des briques plus grandes que celles fournies de base par Qt Quick dans le module Qt Quick Components. Il s’agit de Kirigami, qui suit de près la philosophie définie par le projet : une application utilisant Kirigami aura accès à bon nombre de composants graphiques formant un tout cohérent et intuitif pour l’utilisateur.

Parmi les concepts les plus importants de Kirigami, on peut compter :

  • deux tiroirs, un sur chaque côté de l’écran, rassemblent les actions disponibles ;
  • les options et actions sont séparées en deux groupes : les globales et les contextuelles ; chaque catégorie est assignée à un côté de l’écran (et donc à un tiroir) ;
  • le contenu de l’application est organisé en pages, à travers lesquelles l’utilisateur navigue en faisant défiler horizontalement.

Cette description fait d’office penser que Kirigami est optimisé pour l’utilisation sur des téléphones portables. De fait, l’un des principes directeurs était que toute application devait être facile à utiliser avec une seule main. Cependant, la bibliothèque est aussi prévue pour réaliser des interfaces convergentes, qui s’adaptent à la taille de l’écran (et pas seulement avec une mise à l’échelle) : la même application s’adaptera à la taille disponible sur ordinateur et aux stimuli disponibles.

La première application à l’utiliser est la version mobile de Subsurface, passé à Qt il y a deux ans. Une application Android est disponible, la version iOS est en cours de développement et partage presque l’entièreté du code de la version Android (ce qui est un avantage revendiqué par Qt Quick en général).

Côté technique, Kirigami est compatible avec Android, Linux (tant X11 que Wayland) sur plateformes de bureau, Windows, ainsi que Plasma Mobile. La version iOS est actuellement expérimentale, tandis que que celle pour Ubuntu Touch est en travaux. Kirigami n’est pas encore intégrée à KDE Framework 5, mais cela ne devrait pas tarder, en tant que module de premier niveau (c’est-à-dire que la seule dépendance est Qt).

Source : KDE’s Kirigami UI Framework Gets its First Public Release.

Présentation succincte de Qt Gamepad

Qt 5.7 est arrivé avec quelques nouveaux modules relativement expérimentaux, notamment Qt Gamepad. Comme son nom l’indique, ce module se destine principalement aux jeux et permet d’utiliser des manettes de jeu directement depuis Qt, c’est-à-dire des mécanismes d’entrée avec des boutons, des contrôles directionnels (comme un manche à balai) et parfois des touches. Ce module fournit tant une interface C++ que QML (ce qui est monnaie courante dans les nouveaux développements, comme Qt 3D). Son API n’est pas encore finalisée (le module reste expérimental) et pourrait évoluer dans les versions de Qt à venir. Au niveau de la compatibilité, l’implémentation utilise les API systèmes de Linux, Windows, macOS, iOS et Android, mais aussi la SDL.

Le module se décompose principalement en trois classes, côté C++. Le singleton QGamepadManager liste les manettes connectées et reconnues (accessibles individuellement par QGamepad) et offre un accès de haut niveau aux événements générés par toutes les manettes. QGamepadKeyNavigation se spécialise dans les signaux d’appui sur les touches. Les composants QML (disponibles dans le module QtGamepad 1.0) portent des noms identiques.

La documentation est assez éparse pour le moment (une seule classe C++, rien côté Qt Quick), ICS propose donc un exemple d’utilisation, exploitant QGamepadManager (au lieu de QGamepad, comme dans les exemples fournis avec Qt 5.7). Celui-ci montre comment lister les manettes disponibles, puis connecte des signaux à chaque événement possible pour en afficher les détails.

GamepadMonitor::GamepadMonitor(QObject *parent)
    : QObject(parent)
{
    qDebug() << "QGamePadManager Demo\n";

    auto gamepads = QGamepadManager::instance()->connectedGamepads();
    qDebug() << "Number of gamepads:" << gamepads.size();

    for (auto i : gamepads) {
        QGamepad *gamepad = new QGamepad(i);
        qDebug() << "Gamepad:" << i;
        qDebug() << "  device id:   " << gamepad->deviceId();
        qDebug() << "  name:        " << gamepad->name();
        qDebug() << "  is connected?" << gamepad->isConnected();
    }

    qDebug() << "\nMonitoring for events...\n";

    connect(QGamepadManager::instance(), &QGamepadManager::connectedGamepadsChanged, this,
        []() { qDebug() << "connected gamepads changed:"; });
    connect(QGamepadManager::instance(), &QGamepadManager::gamepadConnected, this,
        [](int deviceId) { qDebug() << "gamepad connected:" << deviceId; });
    connect(QGamepadManager::instance(), &QGamepadManager::gamepadDisconnected, this,
        [](int deviceId) { qDebug() << "gamepad disconnected:" << deviceId; });
    connect(QGamepadManager::instance(), &QGamepadManager::gamepadButtonPressEvent, this,
        [](int deviceId, QGamepadManager::GamepadButton button, double value) { qDebug() << "button press event:" << deviceId << button << value; });
    connect(QGamepadManager::instance(), &QGamepadManager::gamepadButtonReleaseEvent, this,
        [](int deviceId, QGamepadManager::GamepadButton button) { qDebug() << "button release event:" << deviceId << button; });
    connect(QGamepadManager::instance(), &QGamepadManager::gamepadAxisEvent, this,
        [](int deviceId, QGamepadManager::GamepadAxis axis, double value) { qDebug() << "axis event:" << deviceId << axis << value; });
    connect(QGamepadManager::instance(), &QGamepadManager::buttonConfigured, this,
        [](int deviceId, QGamepadManager::GamepadButton button) { qDebug() << "button configured:" << deviceId << button; });
    connect(QGamepadManager::instance(), &QGamepadManager::axisConfigured, this,
        [](int deviceId, QGamepadManager::GamepadAxis axis) { qDebug() << "axis configured:" << deviceId << axis; });
    connect(QGamepadManager::instance(), &QGamepadManager::configurationCanceled, this,
        [](int deviceId) { qDebug() << "configuration canceled:" << deviceId; });
}

Source, image et code source : What’s New in Qt 5.7.0: Qt Gamepad.
Merci à Claude Leloup pour ses corrections.

Qt Quick et Qt 5.8 : changements pour le rendu

À la sortie de Qt 5.0 et de Qt Quick 2, en 2012, l’un des grands changements du côté du rendu était l’utilisation exclusive d’OpenGL 2.0 : OpenGL était vu, à l’époque, comme l’API de choix pour le rendu matériel, peu importe la plateforme (Windows, Linux, macOS, mais aussi sur mobile et dans l’embarqué, avec sa déclinaison OpenGL ES). Cependant, depuis lors, le paysage s’est fortement complexifié.

La solution actuelle ne fonctionne plus

D’un côté, les API de dernières génération ont des concepts radicalement différents (et l’OpenGL nouveau a même changé de nom : Vulkan). De plus, côté embarqué, les processeurs sans GPU OpenGL sont légion, ce qui interdit le déploiement d’applications Qt Quick (à moins d’utiliser une extension autrefois payante, Qt Quick 2D Renderer, compatible avec Qt 5.4 et plus récents). Sur Windows en particulier, l’état des pilotes OpenGL n’était pas toujours excellent (surtout sur les machines où les pilotes graphiques ne sont pas à jour), ce qui impactait directement les applications Qt Quick : dès Qt 5.4, il était possible de choisir, à l’exécution, d’utiliser ANGLE (une implémentation d’OpenGL par-dessus DirectX) ou llvmpipe (une implémentation purement logicielle d’OpenGL).

Ces solutions ne sont en réalité que des emplâtres sur une jambe de bois : un rendu purement logiciel n’est pas envisageable dans bon nombre de situations où la puissance de calcul n’est pas suffisante ; Qt Quick ne peut pas exploiter des API natives, mieux gérées sur chaque plateforme… surtout que le nombre d’API disponibles a fortement augmenté. En effet, le choix ne se porte plus entre Direct3D et OpenGL, notamment puisque les API modernes, de plus bas niveau, sont au nombre de trois : celle d’Apple (Metal), celle de Microsoft (Direct3D 12) et la seule norme multiplateforme (Vulkan). De plus, pour l’ingénierie logicielle, Qt Quick 2D Renderer ne s’intègre pas bien au reste de Qt Quick (il s’agit d’un module séparé).

Une nouvelle génération plus modulaire

Un des objectifs de Qt 5.8 est de refactoriser le code de rendu côté Qt Quick, c’est-à-dire de le découpler d’OpenGL… de le modulariser (c’était le mot clé lors du développement de Qt 5). Ainsi, il devient possible d’utiliser de nouvelles API pour le rendu des scènes Qt Quick, en implémentant une extension qui effectuera la traduction entre le graphe de scène et l’API de rendu. Tout comme il était possible, sous Windows, de passer d’OpenGL à ANGLE à l’exécution, il sera possible de changer d’API à l’exécution. Grâce à l’utilisation d’une représentation assez abstraite de la scène à afficher, chaque extension n’a pas beaucoup de contraintes à respecter dans son implémentation, ce qui permettra de l’utiliser à son plein potentiel.

Cette étape ne fait pas que déplacer des monceaux de code d’un bout à l’autre : des parties de l’implémentation du graphe de scène étaient extrêmement liées à OpenGL. Cela a forcé les développeurs à marquer certaines parties de l’interface publique de Qt comme désapprouvées dès Qt 5.8, de nouvelles API sans ces gênantes dépendances envers OpenGL sont en cours de développement pour les remplacer. Sont notamment concernés les systèmes des matériaux et des particules… mais aussi bon nombre de fichiers d’en-tête dans l’implémentation de Qt Quick : le code C++ incluait ceux d’OpenGL, même si le module Qt Quick 2D Renderer s’occupait de l’affichage (la solution était de définir des fichiers d’en-tête minimaux pour que le code compile — ce qui faisait planter l’application à toute tentative d’appel à OpenGL, forcément impossible).

Direct3D 12 sera le premier concerné par cette refactorisation en profondeur : une extension expérimentale sera livrée avec Qt 5.8 (à côté de celle pour OpenGL, qui garantit la compatibilité avec le code existant), utilisable tant pour les applications traditionnelles (Win32) qu’universelles (UWP). Même si deux gros développeurs derrière Qt (la Qt Company et KDAB) sont membres du consortium Khronos « pour promouvoir Vulkan », il n’y aura pas d’extension pour le moment.

Un moteur de rendu logiciel aux vitamines

Par la même occasion, le moteur de rendu logiciel (ex-Qt Quick 2D Renderer) est retravaillé, notamment au niveau de la performance. Le point principal qui arrivera avec Qt 5.8 est la possibilité de mettre à jour partiellement chaque image affichée, selon les parties qui ont réellement changé dans la scène. Ainsi, une animation qui était autrefois très coûteuse en CPU (une partie pour l’animation elle-même, une plus grosse encore pour redessiner entièrement l’écran à chaque image) deviendra accessible.

L’intégration avec des interfaces à base de widgets avec QQuickWidget sera aussi possible : des applications comme Qt Creator (qui utilisent la classe QQuickWidget) ne pouvaient donc pas utiliser ce moteur de rendu logiciel. Maintenant que le rendu est implémenté au plus près de Qt Quick, le transfert des images entre Qt Quick et les widgets devient possible.

Source : The Qt Quick Graphics Stack in Qt 5.8.
Merci à Claude Leloup pour ses corrections.

Qt WebKit NG TP 3

Le projet continue à revivre, entièrement dans la communauté (sans soutien de la part des développeurs principaux de Qt) : Qt WebKit nouvelle génération voit une troisième préversion technique (TP3) arriver. L’une des grandes nouveautés de cette version est la compatibilité avec les extensions NPAPI et Qt (uniquement pour Windows et X11, pas de macOS pour le moment).

Une partie du travail a consisté à s’approcher du niveau de fonctionnalité de Qt WebKit : les balises <object> et <embed> peuvent gérer du contenu avec des images, l’élément <progress> fonctionne comme attendu, les liens <a> peuvent utiliser l’attribut download. L’API Web SQL Database était malencontreusement désactivé, ce qui est corrigé.

Aussi, les développeurs ont ajouté d’autres fonctionnalités par rapport au module Qt WebKit précédent : les événements DOM de niveau 4, la propriété CSS -webkit-initial-letter (qui nécessite Qt 5.8, les raccourcis pour les polices système.

De manière plus générale, la plupart des modifications proposées sur Gerrit depuis Qt 5.2 ont été intégrées : bon nombre de défauts avaient été corrigés par la communauté, sans être intégrés dans le code de Qt WebKit. Il devient aussi possible de compiler Qt WebKit NG sous forme statique, avec les bibliothèques statiques de Qt.

Télécharger Qt WebKit NG TP 3.

Que contiendra Qt 5.8 ?

Le développement de fonctionnalités pour Qt 5.8 est à peu près terminé : il devait être achevé pour ce lundi 15 août (à cause de problèmes de test des changements dans le code source existant, la date a été repoussée au 22 août, en évitant tout ce qui n’est pas correction de défaut). Ainsi, il est d’ores et déjà possible de dresser le portrait (incomplet) de cette version à venir.

Le plus gros changement concerne Qt Quick : le graphe de scène OpenGL a été refactorisé pour éliminer la dépendance envers OpenGL. L’objectif est de passer facilement à d’autres API pour l’affichage, comme Vulkan ou DirectX 12 : d’ailleurs, cette version 5.8 pourra utiliser directement Direct3D 12 sous Windows (même si le code est expérimental). Il reste cependant à voir à quel point l’implémentation d’autres API pourra les exploiter à leur plein potentiel et ainsi donner des avantages par rapport à l’implémentation OpenGL existante. À l’origine, ce changement était nécessaire pour intégrer le code du module Qt Quick 2D Rendere (autrefois exclusivement propriétaire).

Toujours niveau Qt Quick, des caches ont fait leur apparition pour diminuer les temps de chargement et la consommation de mémoire des applications : le code compilé et les structures de données sous-jacentes aux fichiers QML et JS. Le module Qt Quick Controls 2 propose de nouveaux types (Dialog, DialogButtonBox, ButtonSeparator et MenuSeparator), ainsi que de nouveaux effets pour les styles Material et Universal et un thème System. D’autres types pour mieux s’intégrer avec le système font leur apparition, en étant toutefois expérimentaux : MenuBar, Menu, SystemTrayIcon, ColorDialog, FontDialog, MessageDialog, FileDialog et FolderDialog.

Côté sécurité sur les réseaux, les protocoles TLS PSK (qui se basent sur un échange au préalable de clés symétriques partagées) ont été implémentés dans le module Qt Network (côté serveur) et dans Qt Web Sockets (tant pour le client que le serveur). De même, HTTP 2 est maintenant implémenté.

Dans les derniers arrivés, Qt 3D se focalise sur la maturation (correction de défauts, amélioration de la performance, augmentation de la suite de tests). Qt Charts propose aussi une fonctionnalité de graphiques en chandeliers japonais, principalement utiles dans la finance. Comme prévu, trois nouveaux modules font leur apparition (Qt Wayland Compositor, Qt SCXML et Qt Serial Bus), Qt Gamepad n’est toujours pas finalisé.

Sources : New Features in Qt 5.8, [Development] [Releasing] HEADS-UP: Branching from ‘dev’ to ‘5.8’ ongoing, Qt 5.8 Feature Freeze coming…, [Development] HEADS-UP: Branching from ‘dev’ to ‘5.8’ ongoing, Qt 5.8 Feature Freeze coming….
Merci à Claude Leloup pour ses corrections.

Sortie d’InjeQt 1.1

L’injection de dépendances est un patron de conception qui a de plus en plus la cote. Un de ses objectifs est d’éviter l’utilisation de singletons dans une application (qui provoquent les mêmes troubles que des variables globales) en implémentant l’inversion de contrôle : au lieu que le « code spécifique » (comme une manière de lire des données : du réseau, d’un fichier, etc.) appelle le « code générique » (par exemple, un traitement sur des données), c’est l’inverse qui se produit. Ce « code générique » exploite donc des interfaces pour appeler le « code spécifique » qui lui est fourni en argument. Cette manière de concevoir des applications permet notamment de faciliter les tests : la partie injectée peut être implémentée au niveau du test, ce qui permet de tester exclusivement le « code générique ».

InjeQt est une implémentation de ce patron de conception pour Qt. Ce fait n’est pas si anodin : d’habitude, ces implémentations sont font dans des langages plus dynamiques que le C++, en exploitant des fonctionnalités de réflexion… qui n’existent pas en C++. Par contre, Qt les fournit par son système de métaobjets. InjeQt peut donc proposer des services (du « code spécifique »), pour peu qu’il dérive de QObject (directement ou non). Les dépendances entre classes sont alors explicitées par le biais de la macro INJEQT_SET.

La version 1.1, nouvellement sortie, permet l’injection directe dans un objet par la méthode inject_into(QObject*), ainsi que la définition d’une hiérarchie d’injecteurs (composée de parents et de sous-injecteurs provider_by_parent_injector). Cette dernière fonctionnalité permet notamment à une extension d’une application de récupérer une série de services déjà définis à l’échelle globale (un sous-injecteur) depuis l’injecteur défini dans cette extension (l’injecteur parent).

Télécharger le code source d’InjeQt 1.1.
Source : Injeqt 1.1 and testing Qt applications et le code source d’InjeQt.

Sortie de GammaRay 2.5.1

Il n’aura pas fallu longtemps à KDAB pour annoncer la première mise à jour corrective de GammaRay 2.5. Cette 2.5.1 corrige un certain nombre de défauts :

  • la compilation d’extensions externes est maintenant possible quand GammaRay est installé avec un autre préfixe que celui par défaut ;
  • une condition de course a été éliminée lors de la récupération des paramètres de la sonde ;
  • l’outil de sélection n’affiche plus d’entrées vides avec Qt 4 ;
  • les composants étaient mal dispositionnés dans les barres d’outils flottantes ;
  • le menu contextuel de l’outil de navigation affiche maintenant le nom de outils plutôt que les identifiants internes ;
  • le plantage lorsque la cible de débogage arrête la connexion en premier a été éliminé ;
  • le manuel utilisateur a été enrichi ;
  • le navigateur des codecs n’affiche plus de valeur aléatoire en changeant la sélection.

Le code source est disponible sur GitHub, tout comme des installateurs pour Linux et OS X (les développeurs utilisant Windows n’ont pas encore droit à un installateur).

Source : GammaRay 2.5.1 released.

Nouvelle extension pour Visual Studio : Qt VS Tools

Après quelques années de décrépitude, l’extension Qt pour Visual Studio est de retour. L’ancien code utilisait des parties obsolètes de Visual Studio, il a fallu le réécrire complètement pour obtenir la compatibilité avec les versions les plus récentes. Au passage, il change de nom avec la première préversion Beta publique : désormais, il faudra parler de Qt VS TOols. Ses utilisateurs seront ravis de voir le poids de l’installateur diminuer drastiquement : de 200 Mo à à peine 7 Mo.

Le principal changement est que cette extension est maintenant compatible avec Visual Studio 2013 et 2015 (au lieu de 2008 à la 2012 précédemment). Les principaux types de Qt sont maintenant reconnus dans le débogueur C++ et le contenu des variables est affiché de manière naturelle. Cette extension utilise maintenant le système d’assistants de Visual Studio pour une meilleure intégration à l’environnement. Une fois installée, l’extension offre la possibilité de créer un nouveau projet Qt et de nouveaux fichiers Qt depuis les menus habituels de l’EDI (les assistants nommés Qt5 disparaîtront pour la version finale, ils ne sont pas censés fonctionner).

Dans le futur, cette extension devrait être directement disponible depuis la galerie intégrée (la Visual Studio Gallery) et donc directement installable depuis l’environnement, sans téléchargement extérieur. Au niveau des fonctionnalités, QML devrait débarquer (probablement dans une version à venir), ainsi que la localisation de l’extension et l’accès à l’aide de Qt par la touche F1.

Télécharger Qt VS Tools 2.0 Beta (Visual Studio 2013 et 2015).

Source : From Visual Studio Add-In to Qt VS Tools (Beta).