Tout d'abord, quelques constats sur les kdelibs : elles ne sont pas très modulaires ou réutilisables (même si cela change), ont des fonctionnalités qui devraient plutôt bénéficier à toute la communauté Qt, disposent de classes et modules redondants par rapport à Qt (KHTML et QtWebKit, QLocale et KLocale, etc.). Ainsi, notamment, ses différentes parties dépendent fortement les unes des autre (jusqu'à nécessiter l'exécution de plusieurs processus sur le côté).
Grâce à l'open governance de Qt, il est plus facile de contribuer au framework et donc d'y passer toutes les fonctionnalités fournies par les kdelibs alors qu'elles devraient être dans le framework fondation. De l'autre côté de la frontière, il est dans les projets de faire disparaître la distinction entre applications Qt et applications KDE, de manière technique : les nouveaux KDE Frameworks sont aussi prévus pour une utilisation plus large que dans le seul projet KDE. Cela est une bonne nouvelle pour tous : si votre application aurait pu profiter d'une classe ou l'autre du projet KDE, il ne sera plus nécessaire de prendre tout le projet (ou presque) à côté ; une application KDE pourra également être utilisable plus facilement dans d'autres environnements (dans la lignée des initiatives KDE on Windows et KDE on Mac OS X), bien que sans les fonctionnalités d'intégration à KDE.
Ces changements philosophiques dans la conception des bibliothèques profite en même temps des nouveautés de Qt 5, puisque tout est actuellement développé avec, en tête, tant Qt 4 que Qt 5, en préparant une manière facile de porter le code vers Qt 5 lorsque ce temps sera venu (déplacement des méthodes dans des classes temporaires, par exemple, qui seront obsolètes avec Qt 5 mais très utiles avec Qt 4), ceci ne pouvant pas se faire sans quelques grands changements du côté de l'API par rapport aux kdelibs.
On pourrait rapprocher cette révolution à l'arrivée de KDE 4 : un changement de philosophie, de paradigme de pensée, en causant de vives réactions dans la communauté (évidemment, quelque chose change – et profondément). Malgré ces critiques de jeunesse (que Linux Torvalds, pour rester cohérent avec lui-même, n'a pas hésité à attaquer), KDE 4 est toujours utilisé – les critiques actuelles ne portent plus sur une immaturité ou un changement trop brutal, le logiciel a mûri et les utilisateurs ont accepté de s'adapter. La même chose est arrivée pour GNOME 3 – trop de changements d'un coup. Cette fois, les utilisateurs finaux ne sont pas concernés par ces changements, ils ne les verront pas directement ; les développeurs sont, eux, directement concernés, c'est pourquoi les discussions courent sur ce qu'ils aimeraient voir dans Qt 5, dans les KDE Frameworks 5. Tout comme Qt 5, beaucoup de changements supplémentaires auront lieu en coulisses, comme l'utilisation de nouvelles technologies, sans que l'API doive en souffrir.
Ce nouveau socle est envisagé depuis déjà longtemps et ne devrait pas devenir réellement utilisable avant 2013, tout en prévoyant une migration en douceur – le passage à ce nouveau socle pour les applications ne devrait donc pas mener à KDE 5. Cette douceur est marquée par la série d'Epics, d'objectifs à atteindre pour chaque version,
Ainsi le projet KDE se réaffirme comme utilisateur et protecteur de Qt et de sa liberté, tout en devenant plus gros contributeur, pour le bénéfice de tous. C'est cependant un grand changement dans les relations avec les projets utilisés comme fondation – tout comme Qt, CMake devrait profiter plus des apports du projet KDE.
Voir aussi
Sources
- KDE Frameworks 5: The Community Experiment
- KDE Frameworks 5 for Application Developers
- KDE: Rely on Qt, protect Qt's freedom, contribute to it
- KDE 5.0 roadmap announced
Billet original