Sortie de KDE Frameworks 5

KDE Frameworks 5 (KF5) est sorti le 7 juillet 2014 ! Pour rappel, KF5 c’est le résultat de 3 ans d’efforts pour modulariser les KDElibs, les bibliothèques utilisées par la plupart des logiciels KDE. À cette occasion, elles ont été migrées vers Qt5 et améliorées. Une itération majeure donc, mais une évolution et pas une révolution, ce qui facilite la transition.

La modularisation est un objectif de longue date pour rendre les KDElibs utiles aux développeurs Qt. En effet, les bibliothèques KDE sont, au fur et à mesure de leur évolution, devenues un véritable cadriciel (framework) ou, plutôt, un ensemble de bibliothèques interdépendantes ; ce côté monolithique souvent reproché aux KDElibs limitait son utilité en dehors de KDE.

Note: Cette dépêche est essentiellement une traduction des notes de versions et d'un choix de documentations sur les API de KF5 issus du planet KDE, notamment ces trois là.

Sommaire

• Historique
• Découpage et dépendances
  • Cadriciels fonctionnels
  • Cadriciels d’intégration
  • Cadriciels solution
• Migrer vers KF5
  • CMake
  • C++
  • QML
  • Apports
• Amélioration de l’outillage
• Conclusion

Historique

Quand KDE a été lancé, il y a 15 ans, le développement était centré sur les applications et les bibliothèques arrivaient ensuite, lorsqu’une fonctionnalité était utilisée dans plusieurs applications. Aujourd’hui, les bibliothèques KDE sont la base commune de presque toutes les applications KDE, fournissant des fonctionnalités haut niveau comme les barres d’outils ou les menus, la vérification orthographique et l’accès aux fichiers.

À l’heure actuelle, « KDELibs » est distribué comme un ensemble de bibliothèques interconnectées. Dans le cadre du travail sur KDE Frameworks 5, ces bibliothèques ont été méthodiquement réusinées en un ensemble de modules indépendants et multiplateformes qui seront accessibles à tous les développeurs Qt.

KDE Frameworks, conçu comme une extension à Qt, va enrichir l’environnement de développement de Qt avec des fonctions qui simplifient, accélèrent et réduisent le coût du développement Qt. Par exemple, KArchive (un des premiers cadriciels disponibles) offre la prise en charge de nombreux algorithmes de compression dans une bibliothèque indépendante et simple à utiliser. Envoyez-lui simplement des fichiers ; il n’y a pas besoin de réinventer une fonction d’archivage.

La transition de plateforme à Frameworks est en cours depuis presque 3 ans et est menée par les meilleurs contributeurs KDE. Il a été décidé que les versions de KF5 sortiraient avec un cycle plus adapté au développement des cadriciels de KF5, différent de celui de l’espace de travail Plasma. KF5 devient donc un projet à part de la communauté KDE.

Découpage et dépendances

Les cadriciels de KF5 sont classés selon deux axes :

• Tiers :

  • tiers 1 : aucune dépendance aux autres composants KF5 ;
  • tiers 2 : dépendance possible aux tiers 1 ;
  • tiers 3 : dépendance possible à un autre tiers 3 et aux tiers en-dessous.

• Type (voir plus bas) :

  • fonctionnel ;
  • intégration ;
  • solution.

Cadriciels fonctionnels

Ces cadriciels sont indépendants. Ils n’ont pas de dépendance à l’exécution, mais offrent une fonctionnalité de haut niveau. La liste suivante n'est pas exhaustive quant au nombre de cadriciels disponibles, elle en présente les principales nouveautés.

KArchive est un cadriciel qui prend en charge les archives compressées dans des formats populaires tels zip, 7z et tar, et propose une compression QIODevice pour gzip, bzip2 et xz. KArchive peut extraire n’importe quel fichier dans l’un des formats pré-cités.

KPlotting est un cadriciel de graphe simple qui gère l’anti-crénelage (anti-aliasing), l’empilage et la mise à jour. Il s’occupe de transformer les données soumises en un graphique avec ses axes et ses étiquettes (il prend en compte le passage de l’unité de départ vers les coordonnées en pixels à l’écran).

Threadweaver rend l’écriture de code multithreadé plus facile en utilisant des tâches de fond. Contrairement à QThreadPool, il prend en compte les dépendances entre tâches, les signaux done (réalisé), ainsi que les signaux globaux jobsDone. Il permet aux fils d’exécution d’être suspendus et arrêtés facilement et ne dépend que de QtCore.

KConfig enregistre et restitue des paramètres de configuration. Il présente une API orientée groupe. Il utilise des fichiers INI et des répertoires/annuaires conformes à la norme XDG. Il génère du code en se basant sur les fichiers XML.

KItemModels contient (entre autres) :

• un modèle de filtrage récursif pour les vues en arbre ;
• un modèle de proxy vérifiable pour les arbres et les listes ;
• et un second modèle de proxy, pour restructurer un arbre en liste.

KCoreAddons dispose des éléments suivants (entre autres) :

• KJob : une classe de base pour faire des API asynchrones ;
• file handling classes: directory watching, backup handling, auto save files ;
• Partage des données en cache sur le disque entre applications ;
• des classes de gestion de texte: séparer des chaines de caractères entre les mots et ajouter des points de suspension.

Cadriciels d’intégration

Ceux-ci ont des dépendances en fonction de la plateforme pour l’intégration système.

Sonnet a un correcteur orthographique d’arrière-plan, ainsi que des widgets et des dialogues de configuration. Il fonctionne via des extensions et peut fonctionner avec aspell, hspell, hunspell et enchant.

Solid peut détecter le matériel et informer une application sur les périphériques de stockage et les volumes, le CPU, le statut de la batterie, la gestion d’énergie, le statut de la connexion Internet et des interfaces réseau, et le Bluetooth. Pour les partitions chiffrées, l’énergie et le réseau, des démons en fonctionnement sont nécessaires.

Cadriciels solution

Ceux-là nécessitent que leurs propres démons fonctionnent correctement.

KIO permet à l’utilisateur de parcourir et modifier des fichiers indépendamment du fait qu’ils soient locaux ou distants. Il prend en charge un grand nombre de protocoles (incluant ftp, samba, webdav et nfs), de nombreux formats de fichiers compressés, les miniatures, l’extraction de la musique audio, la corbeille et fish, une vue de gestion de fichiers au travers d'une connexion ssh.

KService est un cadriciel qui fournit des fonctionnalités avancées de gestion des greffons, y compris la recherche sur le disque de ceux-ci à la demande. Il est utile pour les architectures à base de composants, où il permet de charger lors de l’exécution les dépendances nécessaires. Il offre également des fonctions pour trouver les applications associées à un type de fichiers, telles que l’identification de l’application préférée de l’utilisateur pour visualiser les PDF.

Migrer vers KF5

Il existe pas mal de ressources pour migrer sans douleur une application fondée sur les bibliothèques de KDE. On peut :

• lire l’API ;
• examiner les notes de portage ;
• s’aider des projets déjà portés ;
• obtenir de l’aide sur le canal IRC #kde-devel et la liste de diffusion kde-frameworks-devel@kde.org.

Il y a aussi un exemple de projet utilisant KF5.

CMake

A noter, l'adoption des idiomes de CMake : les macros kde4_* ne sont plus utilisées pour créer des cibles, mais les macros CMake, par exemple kde4_add_executable → add_executable. Attention aux dépendances : ${KDE4_KDEUI_LIBS} est remplacé par KF5::WidgetAddons. Notez que ça n’est plus une variable et que, si vous utilisez CMake 3.0, vous obtiendrez un avertissement si elle n’a pas été trouvée. De plus, il n’est plus nécessaire d’utiliser include_directories() pour chaque dépendance, ce sont maintenant les cibles qui s’occupent de ça. Jetez un œil à Extra-cmake-modules : il y a des choses intéressantes dont vous pourriez avoir besoin un jour, de plus c’est une extension CMake, vous pouvez l’utiliser même si Qt ou C++ n’est pas utilisé dans votre projet.

Laurent Montel, développeur KDE – notamment de KDEPIM – a développé des scripts pour faciliter la migration.

C++

Problablement la partie la plus facile, il suffit d’essayer de le faire compiler et de regarder l’API quand cela ne fonctionne pas, puis de recommencer.

Pour commencer le port, c’est en général mieux de s’appuyer sur le cadriciel KDELibs4Support au début. C’est un cadriciel qui contient tous les modules obsolètes, parce que ce sont des fonctionnalités qui ont été déplacées dans Qt5 pour la plupart. Ça aidera à avoir un projet qui compile et, ensuite, vous pouvez supprimer les dépendances obsolètes une par une.

Si vous souhaitez développer en Qt4 pour un moment encore, il peut être utile de faire quelques portages d’abord, par exemple la migration KIcon → QIcon::fromTheme, ce qui réduira la divergence entre la branche Qt4 et la branche Qt5. Ça peut aussi vous aider de faire des tests unitaires avant de migrer, pour éviter de tester toutes les fonctionnalités à la main pendant le portage.

QML

Porter du QML n’est pas trivial, mais il n’y a que quelques projets qui l’utilisent sérieusement. Toutes les technologies sous-jacentes ont changé, ça peut donc devenir épineux. Pour le moment, dans Qt5, il y a deux implémentations de QML. QtQuick 1, qui est celle que nous utilisions dans Qt4 et QtQuick 2 qui est celle que vous voulez utiliser, qui utilise le graphe de scène Qt (Qt Scene Graph) et qui fait de la magie avec le GPU.

Vous pouvez tout d’abord décider de rester en QtQuick 1. Néanmoins, PlasmaComponents a été porté à QtQuick 2, vous devrez donc faire le changement complet pour les plasmoïdes.

Si vous avez avez besoin de faire un port vers QtQuick 2, il y a aussi quelques scripts que vous pouvez utiliser pour faciliter la transition. Pour commencer, vous devez simplement renommer toutes les classes commençant par QDeclarative* vers QQml* et QQuick* ; elles gardent en général le même nom. Par contre, si vous utilisiez les fonctionnalités de QGraphicsView, vous vous êtes fait avoir !

Pour porter le code QML/Javascript vers QtQuick 2, il faut mettre à jour tous les imports. Tous les imports Qt sont montés de version, vous devez donc changer import QtQuick 1.1 pour import QtQuick 2.2, et — dans la même logique — remplacer import org.kde.plasma.components 0.1 par import org.kde.plasma.components 2.0.

Apports

Qt 5 apporte de nombreux nouveaux concepts intéressants, comme QtWebSockets, QtWayland, QtWebEngine ou Qt3D. De plus, cela permet à votre projet d’intégrer correctement le code Qt avec les nouveaux concepts de C++11.

Porter votre projet vers KF5 va l’aider à devenir plus portable et à cibler différentes plateformes.

Amélioration de l’outillage

Séparer les bibliothèques et faire en sorte que le système de compilation fonctionne a provoqué de nombreux cassage de compatibilité. Pour être sûr que tout fonctionne et obtenir des cadriciels compilables et fonctionnels, il était nécessaire d’avoir de meilleurs outils. Une énorme amélioration est l’arrivée d’un système d’intégration continue. Pousser du code pour un cadriciel signifie désormais qu’il est compilé dans un environnement propre et que des tests automatisés sont lancés. C’est aussi utilisé pour construire ses dépendances, donc les problèmes dans le code qui ont pu échapper à l’attention du développeur sont la plupart du temps détectés automatiquement. Les résultats du système d’intégration continue sont souvent disponibles après quelques minutes et, si quelque chose casse, les développeurs reçoivent des notifications sur IRC ou par courriel. Ces courts cycles permettent de résoudre les problèmes quand les modifications effectuées sont encore fraiches dans la tête du développeur. On gagne également du temps, car en récupérant le dernier code en développement, il y a moins de risque d’avoir un code qui ne compile pas.

La compilation déclenche aussi les tests automatisés, qui ont déjà été améliorées récemment, mais restent encore assez loin d’une couverture complète. Avoir des tests automatisés permet de trouver plus facilement les problèmes et améliore la confiance dans le fait qu’un changement particulier ne cause de désastre nulle part.

Ni les compilations continues, ni les tests automatisés ne permettent d’être à 100% sûr que quelque chose ne cassera pas un jour, mais c’est beaucoup moins probable et cela économise du travail aux développeurs. Si un script détecte un problème, c’est probablement beaucoup plus efficace que le test manuel (qui reste nécessaire, évidemment).

Un aspect social de cela est que si quelque chose casse dans les compilations ou tests automatisés, il n’y a pas qu'une seule personne qui est en charge du problème ; ça doit au contraire être un évènement où on « arrête la chaine » et nécessite une attention immédiate — de tout le monde.

Conclusion

La migration vers Qt5, la modularisation et l’amélioration du code des fondations est une avancée technique majeure dans l’histoire de KDE.

Mais les avancées ne sont pas uniquement techniques, l’organisation du projet s’améliore notamment avec plus de relecture de code, une meilleure organisation des dépôts et une unification du flux de travail avec notamment une migration vers GitLab.

La prochaine version de Plasma sera la première à utiliser KDE Frameworks 5 et cela promet d’être intéressant, car, là où le passage de KDE 3 à KDE 4 et de GNOME 2 à GNOME 3 ont été un gros changement de paradigme et technique, il n’est pas prévu de gros changements niveau utilisateur.

Aller plus loin

• Page «Frameworks» sur le wiki de KDE (308 clics)
• Annonce de la sortie sur le site officiel de KDE (229 clics)