Les développeurs de KDE commencent à réfléchir aux KDE Frameworks 6

Qui augure d'un grand nettoyage des API

Qt 6 nous attend au tournant (fin 2020, théoriquement). La version majeure précédente a surtout permis de modulariser la bibliothèque, avec un énorme impact sur le gros utilisateur de Qt qu’est KDE. En effet, la version 5 de KDE Frameworks a suivi le même mouvement de modularisation, notamment pour faciliter l’utilisation de certaines briques dans des applications qui n’ont aucun rapport avec KDE (ou même Linux). Avec Qt 6, KDE envisage aussi de présenter une nouvelle version majeure de KDE Frameworks, en 2020 ou 2021. Bien évidemment, ce sera l’occasion de passer à Qt 6 et d’éliminer toutes les fonctionnalités désapprouvées ces dernières années (comme kdelibs4support), mais pas seulement.

Dans les opérations d’ores et déjà planifiées, le module KDeclarative devrait être divisé en plusieurs morceaux. Ce module contient surtout des composants QML pour accéder au contenu de certains modules de KDE, ces couches devraient être déplacées dans ces modules : pour les classes KIcon (KIconTheme), KIO, KConfig et KCoreAddons. Le sort de KIconTheme est par ailleurs discuté, le module pourrait disparaître au profit des fonctionnalités existantes de QIcon.

Les composants Plasma sont à un endroit un peu étrange, puisque ces composants sont soit des doublons par rapport à Qt Quick Controls 2, soit mal placés par rapport à Kirigami (le jeu de composants Qt Quick de KDE), tout en ayant une apparence assez éloignée de Qt Quick Controls 2 et de Kirigami.

Certaines classes des KDE Frameworks ont des dépendances envers QWidget, alors qu’elles ne sont plus vraiment justifiées (surtout vu que QWidget n’est plus la base unique de toutes les interfaces graphiques Qt). Notamment, cela devrait inclure un équivalent de QAction sans aucune dépendance envers QWidget : cette dépendance du côté de Qt crée des complexités non nécessaires pour KDE.

Solid, le module de requêtes orientées matériel, pourrait être totalement réécrit. En effet, l’architecture actuelle date de l’époque où KDE était utilisé exclusivement sur PC, pas sur téléphone ou tablette, avec les fonctionnalités disponibles dans DBus à l’époque. La nouvelle version devrait avoir une API asynchrone (pour ne pas bloquer l’application qui demande des informations sur le système) et utiliser l’interface ObjectManager de DBus pour récupérer plusieurs entrées d’un coup. Solid pourrait ne proposer, par défaut, que peu de types de propriétés (batterie, périphériques de stockage en général), les autres types de données étant disponibles à travers des extensions.

De manière générale, KDE Frameworks 6 s’alignera sur les prérequis de Qt 6, comme un compilateur C++17 : KDE n’imposera pas de norme plus récente. Cela risquerait de limiter les plateformes gérées par KDE, sans forcément apporter davantage en proportion (std::optional est cité comme apport principal).

Source : liste de discussion KDE Frameworks.