> Qt4 a cassé la compatibilité source avec Qt3 mais ce n'est pas une rupture totale
Tu as des pans entiers de Qt4 qui n'ont pas d'équivalents dans Qt3 ou qui ont été complétement réécrits. Le portage de Qt3 vers Qt4 n'a rien de trivial, il a fallu rajouter un module de compatibilité qt3support pour faciliter le portage.
En comparaison, Qt3 apportait par rapport à Qt2 un meilleur support de l'unicode, de l'i18n et un peu de toilettage pour virer les modules dépréciés.
Je t'accorde que la tournure peut prêter à confusion, les principes de bases de Qt n'ont pas variés (QObject, le système signal-slots, etc ...) mais on ne passe pas de Qt3 à Qt4 comme ça.
> 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.
C'était le seul choix sensé surtout ! Là où le passage de Qt2 -> Qt3 ne demandait finalement que quelques petites retouches, Qt4 imposait de réécrire une bonne partie de KDE4 et de s'appuyer sur la rustine qt3support. C'était soit casser la compatibilité, soit construire un monstre de frankenstein.
> 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.
Le reméde s'est révélé être pire que le mal qu'il était sensé combattre. Parce que le support des différents moteurs multimédias dans Phonon est une catastrophe, de fait, KDE ne maintient que le backend Xine, le backend GStreamer et Quicktime à l'origine maintenu par Nokia n'évolue plus du tout. http://www.mail-archive.com/fedora-devel-list@redhat.com/msg(...) http://www.mail-archive.com/fedora-devel-list@redhat.com/msg(...)
Parmi les différentes couches d'abstraction développés pour KDE4, Phonon fait figure de bon élèves pour dire le peu d'activité autour de Solid ou Decibel.
> 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
Tu m'expliqueras comment GNOME fait alors ...
GStreamer 0.10.x est apparu fin 2005 et pas de changement majeur à l'horizon, la suite a donné raison aux développeurs de GStreamer. Entre temps, à l'exception du sous-ensemble figé dans Qt, l'API de Phonon a plus souvent changé que celle de GStreamer.
> Owen Taylor a commencé à pousser un protocole de communication de bureau commun à KDE et à Gnome, inspiré de DCOP
L'idée est de concevoir un mécanisme d'IPC desktop-agnostic, DBus est plus bas niveau que DCOP. DCOP n'était pas utilisable dans un contexte autre que KDE. DBus a été une remise à plat en prenant compte de l'existant (ICE, Corba, SOAP, etc ...) et en tenant compte des échecs passés comme Bonobo. DBus n'est pas qu'une simple copie améliorée de DCOP.
> La grande force de DBUS, c'est de ne pas apparaitre comme une techno KDE mais une techno neutre, poussée par Red Hat.
J'admire comment les KDE-istes s'approprient DBus alors qu'ils l'ont royalement ignorés pendant plusieurs années.
Les développeurs GNOME ont au moins le mérite de reconnaitre quand ils ont foirés et d'essayer de proposer des solutions neutres.
> 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.
J'ai dit qu'ils étaient rares, pas absents et FreeDesktop ne se limite pas à XDG. Et il est encore plus rare qu'ils soient force de proposition.
Dans l'exemple DBus, KDE a été invité à participer à sa conception mais ils ne l'ont pas fait, ils se sont juste contenté de le reprendre quand ils ont vu que c'était une meilleure alternative que DCOP.
> 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 ».
Quand il existe une problématique autour de l'interopérabilité, la première réaction du développeur KDE c'est de chercher si une solution "standard" existe sinon redévelopper une solution KDE-only sans se soucier des autres. Le développeur GNOME ira d'abord démarrer une discussion sur FreeDesktop *puis* commencera à développer une solution neutre (et une surcouche pour l'intégrer à GNOME) ==> DBus, libcanberra, xdg, PackageKit, ConsoleKit, PolicyKit sont nés comme ça.
FreeDesktop a été créé comme un espace de discussion entre les implémenteurs de bureaux, force est de constater que le réflexe, "je rencontre une problématique, j'en discute sur FreeDesktop avant de commencer quelque chose" n'existe pas chez les développeurs KDE.
Ça ne veut pas dire que les développeurs KDE s'en branlent de l'interopérabilité mais qu'ils devraient être plus proactifs sur FreeDesktop.
Le « je pousse une techno Gnome sur xdg en la déclarant un standard » n'est qu'un fantasme des KDE-istes, la plupart du temps, la discussion/conception sur la techno se fait en amont sur FreeDesktop et non pas à posteriori. Après faut pas venir se plaindre que les méchants développeurs GNOME imposent leurs technos si personne de chez KDE ne daigne participer en amont.
[^] # Re: migration?
Posté par GeneralZod . En réponse à la dépêche Accessibilité: Oracle prend Sun mais se débarrasse de Willie Walker. Évalué à 0.
Tu as des pans entiers de Qt4 qui n'ont pas d'équivalents dans Qt3 ou qui ont été complétement réécrits. Le portage de Qt3 vers Qt4 n'a rien de trivial, il a fallu rajouter un module de compatibilité qt3support pour faciliter le portage.
En comparaison, Qt3 apportait par rapport à Qt2 un meilleur support de l'unicode, de l'i18n et un peu de toilettage pour virer les modules dépréciés.
Je t'accorde que la tournure peut prêter à confusion, les principes de bases de Qt n'ont pas variés (QObject, le système signal-slots, etc ...) mais on ne passe pas de Qt3 à Qt4 comme ça.
> 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.
C'était le seul choix sensé surtout ! Là où le passage de Qt2 -> Qt3 ne demandait finalement que quelques petites retouches, Qt4 imposait de réécrire une bonne partie de KDE4 et de s'appuyer sur la rustine qt3support. C'était soit casser la compatibilité, soit construire un monstre de frankenstein.
> 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.
Le reméde s'est révélé être pire que le mal qu'il était sensé combattre. Parce que le support des différents moteurs multimédias dans Phonon est une catastrophe, de fait, KDE ne maintient que le backend Xine, le backend GStreamer et Quicktime à l'origine maintenu par Nokia n'évolue plus du tout.
http://www.mail-archive.com/fedora-devel-list@redhat.com/msg(...)
http://www.mail-archive.com/fedora-devel-list@redhat.com/msg(...)
Parmi les différentes couches d'abstraction développés pour KDE4, Phonon fait figure de bon élèves pour dire le peu d'activité autour de Solid ou Decibel.
> 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
Tu m'expliqueras comment GNOME fait alors ...
GStreamer 0.10.x est apparu fin 2005 et pas de changement majeur à l'horizon, la suite a donné raison aux développeurs de GStreamer. Entre temps, à l'exception du sous-ensemble figé dans Qt, l'API de Phonon a plus souvent changé que celle de GStreamer.
> Owen Taylor a commencé à pousser un protocole de communication de bureau commun à KDE et à Gnome, inspiré de DCOP
L'idée est de concevoir un mécanisme d'IPC desktop-agnostic, DBus est plus bas niveau que DCOP. DCOP n'était pas utilisable dans un contexte autre que KDE. DBus a été une remise à plat en prenant compte de l'existant (ICE, Corba, SOAP, etc ...) et en tenant compte des échecs passés comme Bonobo. DBus n'est pas qu'une simple copie améliorée de DCOP.
> La grande force de DBUS, c'est de ne pas apparaitre comme une techno KDE mais une techno neutre, poussée par Red Hat.
J'admire comment les KDE-istes s'approprient DBus alors qu'ils l'ont royalement ignorés pendant plusieurs années.
Les développeurs GNOME ont au moins le mérite de reconnaitre quand ils ont foirés et d'essayer de proposer des solutions neutres.
> 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.
J'ai dit qu'ils étaient rares, pas absents et FreeDesktop ne se limite pas à XDG. Et il est encore plus rare qu'ils soient force de proposition.
Dans l'exemple DBus, KDE a été invité à participer à sa conception mais ils ne l'ont pas fait, ils se sont juste contenté de le reprendre quand ils ont vu que c'était une meilleure alternative que DCOP.
> 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 ».
Quand il existe une problématique autour de l'interopérabilité, la première réaction du développeur KDE c'est de chercher si une solution "standard" existe sinon redévelopper une solution KDE-only sans se soucier des autres. Le développeur GNOME ira d'abord démarrer une discussion sur FreeDesktop *puis* commencera à développer une solution neutre (et une surcouche pour l'intégrer à GNOME) ==> DBus, libcanberra, xdg, PackageKit, ConsoleKit, PolicyKit sont nés comme ça.
FreeDesktop a été créé comme un espace de discussion entre les implémenteurs de bureaux, force est de constater que le réflexe, "je rencontre une problématique, j'en discute sur FreeDesktop avant de commencer quelque chose" n'existe pas chez les développeurs KDE.
Ça ne veut pas dire que les développeurs KDE s'en branlent de l'interopérabilité mais qu'ils devraient être plus proactifs sur FreeDesktop.
Le « je pousse une techno Gnome sur xdg en la déclarant un standard » n'est qu'un fantasme des KDE-istes, la plupart du temps, la discussion/conception sur la techno se fait en amont sur FreeDesktop et non pas à posteriori. Après faut pas venir se plaindre que les méchants développeurs GNOME imposent leurs technos si personne de chez KDE ne daigne participer en amont.