Un mois et demi après la sortie de Qt Creator 2.7 beta, voici la version finale de l’EDI Qt, avec (comme à l’habitude) une série de nouvelles fonctionnalités, comme un meilleur support de C++11 (de nouveaux mots-clés, la gestion des fermetures – closures – améliorée ; de plus, il considère par défaut les compilateurs comme C++11 s’il ne les reconnaît pas) et des améliorations sur la refactorisation du code (ajout d’accesseurs en lecture et écriture, notamment).

Avec la relativement récente sortie de Qt 5 et de Qt Quick 2, le support de cette technologie d’interfaces déclaratives a été grandement améliorée, notamment dans l’éditeur de code ; le mode designer graphique fonctionne également avec cette version de Qt Quick. Les paquets Qt Creator actuellement disponibles sont compilés avec Qt 4 et ne supportent pas Qt Quick 2 ; le plus simple est d’attendre Qt 5.0.2, qui sera fourni avec la dernière version de Qt Creator compilée avec Qt 5.

BlackBerry 10 se distingue fortement de ses prédécesseurs par la mise en avant d’une API native, Cascades, au lieu d’une API Java. Cette nouvelle API est construite par-dessus Qt (4 pour le moment, 5 bientôt). Il était donc normal d’attendre de la part de l’EDI un certain support. Notamment, une nouvelle page de paramètres propose de générer toutes les informations nécessaires pour les kits depuis un chemin de NDK, tout en aidant à l’enregistrement et à la génération de certificats développeurs et des autres fichiers requis pour déployer une application sur un périphérique BlackBerry. Un éditeur de fichiers BAR (utilisé pour l’apparence et le comportement des applications) fait également son apparition, avec un mode graphique et un mode XML pur.

QMake est l’outil gérant la compilation avec Qt depuis un bon bout de temps. Son successeur, QBS (Qt Building System), fait apparition dans Qt Creator, avec un support expérimental (à activer manuellement, en chargeant le plug-in associé). Notamment, toutes les sources de Qt Creator proposent tant des fichiers de projet pour QMake que pour QBS.

L’EDI est disponible sur la page des téléchargements du Qt Project.

Le portage de Qt sur Android n’est pas neuf : en janvier 2010, un système graphique fonctionnel était rendu public par BogDan Vatra.

Un peu plus d’un an plus tard, en février 2011, Necessitas sortait au grand jour, avec la première version de Qt utilisable sur Android : https://groups.google.com/forum/#!msg/android-qt/IJ7e98XO7Io/_ti9asJPEsAJ. Fin 2012, le projet Necessitas quittait le giron KDE pour passer au Qt Project, avec intégration dans Qt 5 prévue : http://blog.qt.digia.com/blog/2012/11/08/necessitas-android-port-contributed-to-the-qt-project/.

Début 2013, une branche de développement était créée sur le dépôt Git de Qt, qui vient d’être intégrée au tronc commun : le support d’Android sera bel et bien disponible avec Qt 5.1.

Cette première version s’oriente plus vers les développeurs, pour qu’ils lancent et testent de manière aussi facile que possible leurs applications sur Android. Un support plus finalisé sera disponible pour Qt 5.2, avec plus de possibilités pour le déploiement et le support de plus d’API Android.

En pratique ? Une première démo Qt 5 sur un Nexus 4, un Asus Transformer Pad TF300T et un Nexus 7 ; elle montre un grand nombre d’effets graphiques de Qt Quick 2, dont les shaders, les particules, etc., à soixante images par seconde.

L’API de lecteur multimédia de Qt Multimedia est aussi supportée en QML, ici avec un shader par-dessus.

Cette version de Qt supporte aussi le multitouch, notamment utile pour du dessin à la main. Cette vidéo montre aussi les menus natifs.

Qt 5 utilise l’API Android en version 10 (soit Android 2.3.3), c’est-à-dire qu’il est utilisable sur un très grand nombre de périphériques (selon certaines statistiques, cela concerne à peu près tous les périphériques : http://www.developpez.com/actu/52541/Android-4-0-devient-plus-populaire-que-Gingerbread-qui-a-la-peau-dure-Jelly-Bean-enregistre-une-forte-adoption/). Ici, sur un Huawei Y100 :

Qu’est-ce qui est actuellement supporté ? Les applications Qt Widgets et Qt Quick, le lecteur multimédia QML de Qt Multimedia, les capteurs les plus utilisés dans Qt Sensors, les fonctionnalités multiplateformes de Qt (comme les contrôles Qt Quick), le développement et le déploiement d’applications dans Qt Creator 2.7.

D’autres choses sont prévues, comme la distribution de Qt par Ministro (afin de partager les bibliothèques dynamiques entre les applications), ce qui sera la méthode la plus recommandée pour Qt 5.1. Tous les détails sont disponibles sur le wiki du projet (http://qt-project.org/wiki/Qt5ForAndroid).

Source : http://blog.qt.digia.com/blog/2013/03/13/preview-of-qt-5-for-android/.

De tout go, Digia annonce que Qt 5.2 supportera iOS, soit vers la fin 2013. Cependant, tous les détails ne sont pas encore décidés (comme ce qui concerne les restriction sur l’App Store ou le support de parties plus anciennes du code de Qt). Qt 5.1, en tout cas, contiendra une première version de ce support, le code a été intégré vendredi dernier.

Tout le développement et le déploiement passe par Xcode. Actuellement, la manière de procéder est la création d’un fichier de projet .pro, qui est exporté en un fichier de projet Xcode par QMake (et réexporté à chaque modification), ce dernier étant alors utilisé dans Xcode. Toute l’édition du code peut évidemment se faire en dehors de cet EDI.

Le style Mac de Qt pour plateformes desktop utilise l’API HITheme d’OS X pour l’affichage d’éléments natifs à l’écran. Cependant, cette API n’a pas d’équivalent sur iOS, créer une classe QiOSStyle comme l’actuelle QMacStyle n’est donc pas possible. Les styles multiplateformes tels que le nouveau Fusion sont cependant disponibles. Tous les efforts sur le style des applications seront portés sur les contrôles intégrés dans Qt Quick 2.

Apple limite fortement les possibilités des applications sur iOS. Notamment, il n’est pas possible d’utiliser un compilateur de type JIT, tel que celui utilisé dans V8 – ce qui signifie qu’il n’y aura pas de Qt Quick 2 sur iOS pour le moment. Ce problème est bien connu et une solution est à l’étude.

Actuellement, déjà quelques modules fonctionnent correctement : les widgets, les graphics view, Qt Quick 1, OpenGL, les éléments tactiles et d’orientation.

Pour tester cette première ébauche, il est nécessaire d’avoir Xcode installé (avec les certificats et le périphérique configurés). Ensuite, cloner qtbase

et le compiler (soit pour le périphérique, soit pour le simulateur).

Récupérer une démo et l’ouvrir dans Xcode :

Source : http://blog.qt.digia.com/blog/2013/03/05/qt-for-ios-preview/

Windows 8 RT

Windows 8 est sorti récemment, avec une nouvelle plateforme de développement : le Windows Runtime. Le système fournit alors deux modes : classique, semblable à celui de Windows 7 (au menu Démarrer près) ; moderne, anciennement Metro, une interface prévue pour les tablettes et autres smartphones. Les applications pour ce deuxième mode sont construites avec une nouvelle API, Windows Runtime, très semblable à celle de Windows Phone 8.

Le travail de recherche autour de l’utilisation de Qt dans un contexte RT ont été lancées par Andrew Knight (Digia). Les résultats sont d’ores et déjà visibles dans la branche winrt du dépôt qtbase. Avec quelques modifications de Kamil TrzciÅ„ski et la sortie de Qt 5.0, il serait temps de faire décoller ce port de Qt, une manière de compléter l’offre multiplateforme du framework (déjà fournie en ce qui concerne les plateformes mobiles, avec des ports pour Android et iOS, les systèmes mobiles les plus répandus, capitalisant pas loin de nonante pour cent des smartphone vendus).

État du port

Ce port se focalise actuellement sur le cÅ“ur de Qt (le module Qt Core). Les widgets ne seront probablement pas supportés dans le futur proche, étant donné que les développeurs préfèrent dépenser leur énergie sur des manières plus adaptées à l’environnement RT de créer des interfaces graphiques (forcément plus dynamiques), comme Qt Quick.

De même, il est probable que l’élément WebView de QML sera implémenté sur le moteur IE 10, au lieu d’utiliser WebKit 2 (comme pour le reste de Qt). Cela pourrait amener quelques problèmes de compatibilité des applications (IE 10 n’utilisant pas le même moteur de rendu), cependant.

La première étape sera d’afficher de simples fenêtres à l’écran. Ensuite, il est prévu de porter ANGLE, afin d’obtenir le support d’OpenGL ES 2.0, requis pour QML 2.

Vu que le projet est encore actuellement dans ses premières étapes, il n’est pas prévu qu’il soit intégré pour Qt 5.1, plus probablement quelque chose pour Qt 5.2.

Un plug-in pour Qt Creator est aussi en cours de développement, mais il est bien moins avancé : https://gitorious.org/~aknight/qt-creator/aknights-qt-creator.

Windows Phone 8

La situation semble plus simple, puisque tous les modules essentiels de Qt compilent – malgré des fonctionnalités manquantes, à cause de la non-implémentation des détails spécifiques à la plateforme, cela fonctionne bien. En effet, les API disponibles à WinRT sont plus restreintes que celles disponibles sur Windows Phone 8. Notamment, tout le côté réseau doit être réimplémenté presque de zéro, Winsock2 n’étant pas disponible.

La compilation utilise Visual Studio 2012, avec la chaîne de compilation ARM et de nouvelles spécifications pour QMake côté Qt. La procédure complète est plus compliquée qu’une compilation croisée plus standard de Qt, plus expérimentale (c’est le moins qu’on puisse dire), à cause du manque de maturité du port : http://ayufan.eu/2013/02/qt5-and-windows-phone-8/.

Sources

http://blog.qt.digia.com/blog/2013/02/15/port-to-windows-runtime-kick-started/, http://ayufan.eu/2013/02/qt5-and-windows-phone-8/, http://qt-project.org/wiki/WinRT