Je sens le besoin d'apporter quelques commentaires :
« Contrairement à Qt3, Qt4 a été une rupture totale par rapport à son prédécesseur »
Alors, il faut pas exagérer. Qt4 a cassé la compatibilité source avec Qt3 mais ce n'est pas une rupture totale. On retrouve les mêmes concepts, il y a des pans entiers de la lib qui n'ont pas bougé.
Un portage Qt3 vers Qt4 d'une application moyenne totalement Qt prends quelques semaines.
« KDE n'a eu d'autres choix que de revoir les fondations »
Ca, c'est complètement faux. KDE avait différents choix possibles.
Lors de la dernière transition incompatible Qt2 vers Qt3, KDE a fait le choix de se contenter d'adapter KDE aux nouveaux concepts de Qt 3 de sorte que la sortie de KDE 3.0 n'a guère été plus difficile que la sortie d'une version 2.x .
La question s'est posée lors du passage à Qt 4 de reprendre la même stratégie et de faire une transition rapide et en douceur.
Après moultes discussions sur la mailing list, la conclusion a été que la base de code actuelle datant des années 2000 (première version de KDE 2), ce serait une bonne idée de profiter de la rupture de source de Qt pour retravailler le coeur de KDE et se donner la possibliité de faire des changements incompatibles.
Contrairement à ce que tu affirmes, c'est donc un choix responsable de KDE d'avoir refondu les fondations et non quelque chose qui aurait été imposé par les changements de Qt.
A partir de là, KDE a pris quelques décisions importantes :
- le choix du demon pour le son arts s'est révélé mauvais. Pour ne plus reproduire ce schéma de dépendance, KDE a choisi d'abstraire totalement la couche son de façon à pouvoir gérer facilement plusieurs démons sonores au choix. Cela a donné phonon. Note au passage que les gens de gstreamer n'ayant pas à coeur de conserver la compatiblité binaire entre des releases, phonon est nécessaire même pour l'intégration de gstreamer dans KDE (ou bien il faut garder la même version de gstreamer sur tout le cycle KDE 4. Bof).
- en même temps, c'est la période ou Owen Taylor a commencé à pousser un protocole de communication de bureau commun à KDE et à Gnome, inspiré de DCOP. KDE a fait le choix de se séparer de DBUS et de passer à DCOP pour soutenir l'interopérabilité.
- le mainteneur de kicker a estimé que la quantité de travail pour le porter sur Qt4 et KDE4 serait supérieure à ce qu'il faudrait pour le réécrire. Qui plus est une réécriture permettrait de corriger pas mal de bugs, problèmes de conception et ouvrirait la voie pour des innovations. Cela a donné Plasma. Fondamentalement, plasma aurait pu être introduit au dessus de KDE3 / Qt3 en dépréciant progressivement kicker et autres.
- KWIN n'a presque pas bougé, le mainteneur en a juste profité pour tirer partie des derniers progrès de Xorg pour rajouter des fonctionnalités populaires (transparence, 3D, ...)
- akonadi était déjà en gestation face à la complexité de maintenir des informations de contact à travers plusieurs applications (KMail, Konteact, Konverstation, ....)
- kio n'a pas bougé, kconfig non plus, kpart non plus, toutes ces technos qui tournent depuis 10 ans chez KDE restent de bonne facture.
Au final, la transition a été longue et douloureuse, mais pour permettre un futur plus tranquille.
Un mot sur DBUS vs DCOP. Contrairement à ce qui a été dit plus haut, DBUS est bien une adaptation plus de DCOP. On y retrouve tous les concepts de DCOP. Les changements ont été de se passer de ICE (la couche d'échange utilisée par DCOP) pour une couche plus bas niveau. Le noyau ayant évolué depuis le temps ou DCOP a été conçu, une intégration plus basse a pu être possible.
Je salue la réussite du plan de communication de Gnome, qui a réussi à mettre à la poubelle tout ce qu'était bonobo en arrivant à faire croire aujourd'hui qu'il s'agissait d'une transition.
La grande force de DBUS, c'est de ne pas apparaitre comme une techno KDE mais une techno neutre, poussée par Red Hat. Ca et une conception légèrement plus moderne ont permis son adaption par Gnome.
Je salue l'ouverture de KDE qui a accepté, au nom de l'interopérabilité, de renoncer à une techno qu'il avait développé lui-même (basée sur ICE comme le rappelle fort justement mon contradicteur) pour adopter une réécriture du même concpet par Gnome.
Je salue l'ouverture de Gnome qui a accepté une techno KDE maquillée sous une rééecriture. Je me rappellerai d'ailleurs toujours ce mail sur kde-core-devel de Owen : «if you think it's hard to convince KDE to adopt DBUS, think how hard it is for me to convince Gnome to adopt it ».
« C'est pas un mystère que les développeurs KDE se font rares sur FreeDesktop. »
Encore une affirmation tout à fait erronée. Abonne toi à la liste xdg et tu verras que les développeurs KDE sont tout autant présent que les développeurs Gnome, et que l'interopérabilité est un souci présent des deux côtés.
On peut seulement regretter que une partie des développeurs Gnome voient l'interopérabilité comme « je pousse une techno Gnome sur xdg en la déclarant un standard ».
Notamment, on a vu plusieurs fois le scenario suivant se répéter :
- une techno existe chez KDE pour gérer une problématique (les thèmes, les notifications, etc)
- un développeur chez Gnome décide de répondre à la même problématique pour le bureau Gnome
- il développe sa techno sans regarder ce qui a été fait chez KDE
- il ignore les suggestions et remarques des développeurs de KDE qui proposent de rendre le système interopérable avec l'existant, ou bien adapté aux besoins de KDE
- après quelques années, il trouve que son truc est bien et le déclare comme un standard sur xdg
- il joue les vierge offusquées quand KDE expose les raisons pour lesquelles ledit standard ne pourra pas être adopté par KDE, raisons qui ont été exposés avant même que le développement dudit bousin aie commencé, et raisons qui ont été royalement ignorées.
Ce scenario s'est reproduit plusieurs fois, au point que freedesktop-xdg a failli être dissous. Je t'invite à lire les messages de cette liste d'il y a un an ou deux pour voir la chose en réel.
Heureusement, freedesktop a plus de succès à son actif que d'échec mais la technique « je déclare ma techno proprio comme un standard et KDE est un gros con parce qu'il l'utilise pas », ca énerve.
Je suis triste de constater d'ailleurs que dans l'esprit des gens, c'est KDE le mauvais joueur.
[^] # Re: migration?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 9.
« Contrairement à Qt3, Qt4 a été une rupture totale par rapport à son prédécesseur »
Alors, il faut pas exagérer. Qt4 a cassé la compatibilité source avec Qt3 mais ce n'est pas une rupture totale. On retrouve les mêmes concepts, il y a des pans entiers de la lib qui n'ont pas bougé.
Un portage Qt3 vers Qt4 d'une application moyenne totalement Qt prends quelques semaines.
« KDE n'a eu d'autres choix que de revoir les fondations »
Ca, c'est complètement faux. KDE avait différents choix possibles.
Lors de la dernière transition incompatible Qt2 vers Qt3, KDE a fait le choix de se contenter d'adapter KDE aux nouveaux concepts de Qt 3 de sorte que la sortie de KDE 3.0 n'a guère été plus difficile que la sortie d'une version 2.x .
La question s'est posée lors du passage à Qt 4 de reprendre la même stratégie et de faire une transition rapide et en douceur.
Après moultes discussions sur la mailing list, la conclusion a été que la base de code actuelle datant des années 2000 (première version de KDE 2), ce serait une bonne idée de profiter de la rupture de source de Qt pour retravailler le coeur de KDE et se donner la possibliité de faire des changements incompatibles.
Contrairement à ce que tu affirmes, c'est donc un choix responsable de KDE d'avoir refondu les fondations et non quelque chose qui aurait été imposé par les changements de Qt.
A partir de là, KDE a pris quelques décisions importantes :
- le choix du demon pour le son arts s'est révélé mauvais. Pour ne plus reproduire ce schéma de dépendance, KDE a choisi d'abstraire totalement la couche son de façon à pouvoir gérer facilement plusieurs démons sonores au choix. Cela a donné phonon. Note au passage que les gens de gstreamer n'ayant pas à coeur de conserver la compatiblité binaire entre des releases, phonon est nécessaire même pour l'intégration de gstreamer dans KDE (ou bien il faut garder la même version de gstreamer sur tout le cycle KDE 4. Bof).
- en même temps, c'est la période ou Owen Taylor a commencé à pousser un protocole de communication de bureau commun à KDE et à Gnome, inspiré de DCOP. KDE a fait le choix de se séparer de DBUS et de passer à DCOP pour soutenir l'interopérabilité.
- le mainteneur de kicker a estimé que la quantité de travail pour le porter sur Qt4 et KDE4 serait supérieure à ce qu'il faudrait pour le réécrire. Qui plus est une réécriture permettrait de corriger pas mal de bugs, problèmes de conception et ouvrirait la voie pour des innovations. Cela a donné Plasma. Fondamentalement, plasma aurait pu être introduit au dessus de KDE3 / Qt3 en dépréciant progressivement kicker et autres.
- KWIN n'a presque pas bougé, le mainteneur en a juste profité pour tirer partie des derniers progrès de Xorg pour rajouter des fonctionnalités populaires (transparence, 3D, ...)
- akonadi était déjà en gestation face à la complexité de maintenir des informations de contact à travers plusieurs applications (KMail, Konteact, Konverstation, ....)
- kio n'a pas bougé, kconfig non plus, kpart non plus, toutes ces technos qui tournent depuis 10 ans chez KDE restent de bonne facture.
Au final, la transition a été longue et douloureuse, mais pour permettre un futur plus tranquille.
Un mot sur DBUS vs DCOP. Contrairement à ce qui a été dit plus haut, DBUS est bien une adaptation plus de DCOP. On y retrouve tous les concepts de DCOP. Les changements ont été de se passer de ICE (la couche d'échange utilisée par DCOP) pour une couche plus bas niveau. Le noyau ayant évolué depuis le temps ou DCOP a été conçu, une intégration plus basse a pu être possible.
Je salue la réussite du plan de communication de Gnome, qui a réussi à mettre à la poubelle tout ce qu'était bonobo en arrivant à faire croire aujourd'hui qu'il s'agissait d'une transition.
La grande force de DBUS, c'est de ne pas apparaitre comme une techno KDE mais une techno neutre, poussée par Red Hat. Ca et une conception légèrement plus moderne ont permis son adaption par Gnome.
Je salue l'ouverture de KDE qui a accepté, au nom de l'interopérabilité, de renoncer à une techno qu'il avait développé lui-même (basée sur ICE comme le rappelle fort justement mon contradicteur) pour adopter une réécriture du même concpet par Gnome.
Je salue l'ouverture de Gnome qui a accepté une techno KDE maquillée sous une rééecriture. Je me rappellerai d'ailleurs toujours ce mail sur kde-core-devel de Owen : «if you think it's hard to convince KDE to adopt DBUS, think how hard it is for me to convince Gnome to adopt it ».
« C'est pas un mystère que les développeurs KDE se font rares sur FreeDesktop. »
Encore une affirmation tout à fait erronée. Abonne toi à la liste xdg et tu verras que les développeurs KDE sont tout autant présent que les développeurs Gnome, et que l'interopérabilité est un souci présent des deux côtés.
On peut seulement regretter que une partie des développeurs Gnome voient l'interopérabilité comme « je pousse une techno Gnome sur xdg en la déclarant un standard ».
Notamment, on a vu plusieurs fois le scenario suivant se répéter :
- une techno existe chez KDE pour gérer une problématique (les thèmes, les notifications, etc)
- un développeur chez Gnome décide de répondre à la même problématique pour le bureau Gnome
- il développe sa techno sans regarder ce qui a été fait chez KDE
- il ignore les suggestions et remarques des développeurs de KDE qui proposent de rendre le système interopérable avec l'existant, ou bien adapté aux besoins de KDE
- après quelques années, il trouve que son truc est bien et le déclare comme un standard sur xdg
- il joue les vierge offusquées quand KDE expose les raisons pour lesquelles ledit standard ne pourra pas être adopté par KDE, raisons qui ont été exposés avant même que le développement dudit bousin aie commencé, et raisons qui ont été royalement ignorées.
Ce scenario s'est reproduit plusieurs fois, au point que freedesktop-xdg a failli être dissous. Je t'invite à lire les messages de cette liste d'il y a un an ou deux pour voir la chose en réel.
Heureusement, freedesktop a plus de succès à son actif que d'échec mais la technique « je déclare ma techno proprio comme un standard et KDE est un gros con parce qu'il l'utilise pas », ca énerve.
Je suis triste de constater d'ailleurs que dans l'esprit des gens, c'est KDE le mauvais joueur.