Plus de la moitie des specs de freedsktop ont ete proposees par KDE, discutees puis adoptees. Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.
Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.
> M'enfin, Gnome a fait au moins cinq fois plus de propositions.
Je m'eleve en faux contre cette proposition. Tu parles peut-etre du nombre de projets utilisant glib heberges sur freedesktop ? On peut pas vraiment appeler ca developper de l'interoperabilite a partir de cela.
Une grande partie du travail de freedesktop, c'est de proposer des specifications, avec si possible une ou plusieurs implementaitons. Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne. La force de dbus, c'est donc : un serveur + une spec de communication et maintenant deux implementations de la partie client.
> Pour prendre un exemple chaud, Gnome fait un serveur multimédia. C'est Gstreamer,
C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants. C'est sur que si tu comptes comme ca, Gnome a beaucoup de projets.
Gstreamer n'assure pas la compabilite binaire ni source entre version. C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire. Si l'utilisateur met a jour sa mandarke et que tout d'un coup, toutes les applications KDE n'ont plus de son parce que gstreamer a ete mis a jour, ce n'es tpas bien (note que c'est le comportement a l'heure actuelle).
La solution, c'est de construire une couche d'isolation qui pourra fonctionner par exemple avec les diverses versions de gstreamer et aussi avec d'autres serveurs son, et qui elle sera stable. C'est phonon. Une api pour fournir des services sons aux applications KDE sans que celles-ci aient besoin de savoir si le serveur son installe est arts, esd, gstreamer v1, gstreamer v2, gstreamer v3, nmm ou autres.
Phonon en est encore a la phase experimental. Deja quand on voit comment il est mal recu, je vois mal comment on pourrait le pousser. J'espere pour ma part qu'il suivra le chemin de DCOP, c'est a dire qu'on realisera qu'il resoud un reel probleme et apporte qqch d'util, et qu'a partir de la, soit on adaptera phonon pour etre independant de KDE, soit on redeveloppera un wrapper de serveur son utilisable par tous les projets.
[^] # Re: Tango : bof
Posté par Philippe F (site web personnel) . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 7.
Plus de la moitie des specs de freedsktop ont ete proposees par KDE, discutees puis adoptees. Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.
Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.
> M'enfin, Gnome a fait au moins cinq fois plus de propositions.
Je m'eleve en faux contre cette proposition. Tu parles peut-etre du nombre de projets utilisant glib heberges sur freedesktop ? On peut pas vraiment appeler ca developper de l'interoperabilite a partir de cela.
Une grande partie du travail de freedesktop, c'est de proposer des specifications, avec si possible une ou plusieurs implementaitons. Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne. La force de dbus, c'est donc : un serveur + une spec de communication et maintenant deux implementations de la partie client.
> Pour prendre un exemple chaud, Gnome fait un serveur multimédia. C'est Gstreamer,
C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants. C'est sur que si tu comptes comme ca, Gnome a beaucoup de projets.
Gstreamer n'assure pas la compabilite binaire ni source entre version. C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire. Si l'utilisateur met a jour sa mandarke et que tout d'un coup, toutes les applications KDE n'ont plus de son parce que gstreamer a ete mis a jour, ce n'es tpas bien (note que c'est le comportement a l'heure actuelle).
La solution, c'est de construire une couche d'isolation qui pourra fonctionner par exemple avec les diverses versions de gstreamer et aussi avec d'autres serveurs son, et qui elle sera stable. C'est phonon. Une api pour fournir des services sons aux applications KDE sans que celles-ci aient besoin de savoir si le serveur son installe est arts, esd, gstreamer v1, gstreamer v2, gstreamer v3, nmm ou autres.
Phonon en est encore a la phase experimental. Deja quand on voit comment il est mal recu, je vois mal comment on pourrait le pousser. J'espere pour ma part qu'il suivra le chemin de DCOP, c'est a dire qu'on realisera qu'il resoud un reel probleme et apporte qqch d'util, et qu'a partir de la, soit on adaptera phonon pour etre independant de KDE, soit on redeveloppera un wrapper de serveur son utilisable par tous les projets.