Sortie de KDE Frameworks 5

81
14
juil.
2014
KDE

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.

Logo KDE en cours de construction — CC-By-Sa 3.0/GFDL 1.2

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 .

Sommaire

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

Schéma des relations entre les composants de KF5 — CC-By 3.0 unported

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_executableadd_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.

Nouveau Konqui

  • # Côté utilisateur et processus induits

    Posté par . Évalué à 8.

    En tant qu'utilisateur, est-ce que les applications KDE5 ne généreront plus une poignée de processus résidents et permanents ?

    Mon bureau n'est ni GTK ni Qt, mais j'utilise bien sûr des applications de ces frameworks. Sans problème. Par contre, les rares applis KDE auxquelles je recours parfois, comme Tellico, ont l'inconvénient de laisser traîner en mémoire 4 ou 5 programmes résidents, dont Gamin qui est apparemment un processus de surveillance des fichiers. En pratique, je fais le ménage à coup de kill, mais j'apprécierais que les programmes KDE aient une option : « remportez vos saletés, et laissez l'endroit comme vous l'avez trouvé. »

    • [^] # Re: Côté utilisateur et processus induits

      Posté par (page perso) . Évalué à 10.

      Hmm, bizarre, pour moi gamin est un truc obsolète et ne fait pas du tout parti des dépendances de KDE, pas sous Arch et Kubuntu/Debian en tout cas…

      • [^] # Re: Côté utilisateur et processus induits

        Posté par (page perso) . Évalué à 4.

        KDE n’a pas besoin de gamin pour fonctionner (sous les systèmes Linux, KDE utilise inotify).

        En tant qu'utilisateur, est-ce que les applications KDE5 ne généreront plus une poignée de processus résidents et permanents ?

        À mon avis, si l’application ne dépend pas d’un cadriciel qui nécessite un «démon KDE», il y a de bonnes chances pour que celui-ci ne soit plus lancé.

        Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Côté utilisateur et processus induits

        Posté par . Évalué à 2.

        Je maintiens. Je suis en Debian testing, et j'ai bien 8 processus KDE lancés par l'appli Tellico, dont ce "truc obsolète" de Gamin :

        bibi  1812 10550 19 20:44 pts/9    00:00:01 tellico
        bibi  1828     1  0 20:44 ?        00:00:00 kdeinit4: kdeinit4 Runnin
        bibi  1829  1828  0 20:44 ?        00:00:00 kdeinit4: klauncher [kdei
        bibi  1831     1  1 20:44 ?        00:00:00 kdeinit4: kded4 [kdeinit]  
        bibi  1833     1  0 20:44 ?        00:00:00 /usr/lib/gamin/gam_server
        bibi  1836  1828  0 20:44 ?        00:00:00 kdeinit4: kio_file [kdein
        bibi  1837  1828  0 20:44 ?        00:00:00 kdeinit4: kio_file [kdein
        bibi  1838  1828  0 20:44 ?        00:00:00 kdeinit4: kio_file [kdein
        bibi  1839  1828  0 20:44 ?        00:00:00 kdeinit4: kio_file [kdein
        bibi  1853 10550  0 20:44 pts/9    00:00:00 ps -fu bibi
        
        • [^] # Re: Côté utilisateur et processus induits

          Posté par . Évalué à 5. Dernière modification le 16/07/14 à 07:39.

          Je suis en full KDE sous Archlinux et je n'ai ni Tellico ni gamin. Pareil si j'essaie Kubuntu.

          Tellico ne fait pas partie de KDE SC, et gamin n'est pas un composant KDE.

          max-laptop% pacman -Ss tellico
          community/tellico 2.3.9-1
          A collection manager for KDE
          max-laptop% pacman -Qs gamin
          local/gamin 0.1.10-8
          File and directory monitoring system defined to be a subset of the FAM (File
          Alteration Monitor)
          max-laptop% sudo pacman -Rsnc gamin
          [sudo] password for max:
          vérification des dépendances…
          :: wine peut nécessiter samba

          Paquets (4): codeblocks-13.12-2 iniparser-3.1-4 samba-4.1.9-1 gamin-0.1.10-8

          Taille totale supprimé : 66,59 MiB

          :: Voulez-vous désinstaller ces paquets ? [O/n]

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Côté utilisateur et processus induits

            Posté par . Évalué à 1.

            Gamin a été remplacé par fam. Sous Debian, libgamin0 fournit (provides) un équivalent à libfam0. Mon PC a été installé il y a des années, et Debian testing ne force pas le passage à la nouvelle implémentation, donc j'étais resté avec Gamin.

            Cette histoire de gamin (désolé) ne change rien à ma remarque initiale. Si je lance audex ou k3b, j'ai aussi des processus KDE qui sont créés et résident en mémoire après avoir quitté l'application.

            • [^] # Re: Côté utilisateur et processus induits

              Posté par (page perso) . Évalué à 3.

              Cet histoire de processus KDE qui reste en place, n'est-ce pas le cache du système ? je veux dire que ces applications resteront en mémoire tant que tu en as assez pour tes activités et relancer plus rapidement tes applications KDE si nécessaire ?

              Tu peux confirmer cette hypothèse en remplissant ta RAM, si à un moment tes processus KDE disparaissent, c'est que c'était bien du cache pur. Dans ce contexte là ils ne consomment rien en ressource.

              • [^] # Re: Côté utilisateur et processus induits

                Posté par . Évalué à 4.

                Si tu as le nom du processus dans la liste des processus, alors c'est pas le cache du système. Si c'était le cache du système, ce seraient seulement les fichiers d'exécutables qui seraient dans le cache tant qu'il reste de la mémoire libre. Cela permet de relancer plus vite l'application.

            • [^] # Re: Côté utilisateur et processus induits

              Posté par . Évalué à 7.

              C'est justement un des points forts de KDE, car les process kioslave accède aux disques, mais tous les processus KDE utilisene les mêmes, ce qui donne une meilleure empreinte en RAM, etc. si tu utilises beaucoup de processus KDE.

              Ce qu'il faudrait peut-être ajouter, c'est un suicide de ces process si plus personne ne les utilise depuis un certain temps (0 pouvant être acceptable). Une nouvelle feature à proposer pour KDE ?

            • [^] # Re: Côté utilisateur et processus induits

              Posté par . Évalué à 3.

              Pour être plus exact, gamin serait plutôt un remplaçant à FAM : il est plus récent que FAM, s'interface avec des sous-systèmes plus récent dans Linux (inotify au lieu de dnotify par exemple), est moins "dangereux" (fonctionne en tant qu'utilisateur qui a besoin de la fonctionnalité, pas en tant que root) et est censé consommé moins de ressources.

              Il fournit la même API que FAM, c'est pour ça que les dépendances dans Debian sont définies comme ça.

              (cf. https://people.gnome.org/~veillard/gamin/overview.html)

    • [^] # Re: Côté utilisateur et processus induits

      Posté par (page perso) . Évalué à -5.

      Hmm, bizarre, pour moi gamin est un truc obsolète et ne fait pas du tout parti des dépendances de KDE, pas sous Arch et Kubuntu/Debian en tout cas…

    • [^] # Re: Côté utilisateur et processus induits

      Posté par . Évalué à 1.

      Concrètement, est-ce que c'est possible ? Y a-t-il une solution qui ne demande pas à l'utilisateur d'intervenir ?

  • # Intégration directement dans Qt

    Posté par . Évalué à 8.

    Je me pose la question suivante. Pourquoi certaines fonctions n'ont pas été intégrées directement à Qt ? Je pense en particulier à Threadweaver ; pourquoi ne pas avoir directement amélioré QThreadPool et compagnie ?

    Comment est fait le choix d'intégré une fonction à Qt ou bien à KF5 ?

    • [^] # Re: Intégration directement dans Qt

      Posté par (page perso) . Évalué à 10.

      Beaucoup de fonctions ont été intégrés à Qt: https://community.kde.org/Frameworks/Epics/Contributions_to_Qt5

      Il y a une différence de licence entre Qt et KDE: Les contributions à Qt ne sont acceptées que si l'auteur donne une licence permanente à Digia pour faire ce qu'il veulent avec la contribution (et en particulier vendre des licences Qt).

      Je suppose que c'est une raison pour laquelle tous les framework ne sont pas dans Qt, et que certains reste dans la communauté KDE.

      Aussi, il n'y a pas de raison de mettre tout dans Qt.

    • [^] # Re: Intégration directement dans Qt

      Posté par . Évalué à -1.

      Quoi ? Tu ne connais pas les principes du refactoring ?

      On code d'abord, ensuite on contemple le résultat ;-)

  • # D’autres scripts de portage vers KF5

    Posté par (page perso) . Évalué à 6.

    http://www.aegiap.eu/kdeblog/2014/07/whats-new-in-kf5-porting-script/

    • convert-ksavefile.pl converts KSaveFile to QSaveFile
    • convert-ksharedptr.pl convert KSharedPtr to QExplicitlySharedDataPointer
    • convert-ksplashscreen.pl converts KSplashScreen to QSplashScreen

    • convert-kimageio.pl converts to QImageIO

    • convert-kglobal-removeAcceleratorMarker.pl helps to convert KGlobal::removeAcceleratorMarker(…)

    • port-kauthactions.pl, it tries to port to new KAuth API

    • adapt_knewstuff3_includes.pl, fix new knewstuff3 include path

    On voit à nouveau quatre exemples de classes qui ont été soit ajoutées à Qt, soit améliorés pour que la classe K* deviennent inutile.

    Écrit en Bépo selon l’orthographe de 1990

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.