> Peut-être préfères-tu, comme dit plus bas, ce qui se passe en ce moment avec le dev d'amarok (ou de tout autre lecteur multimédia, juk par exemple) obligé de développer un connecteur pour xine, un autre pour gstreamer (qui d'ailleurs est plus ou moins laissé à l'abandon), le tout pour *simplement* lire des fichiers audio.
Non.
Ici tu démontres qu'avoir plusieurs backends sucks. Tu démontres aussi que maintenir une interface pour plusieurs backends sucks aussi.
> Il ne s'agit ni plus ni moins que de mutualiser les efforts
Dans l'optique de supporter plusieurs backends !
Mais tu viens de le démontrer, cette démarche sucks et depuis de nombreuses années.
> d'assurer un code qui fonctionne puisqu'il sera officiellement inclus dans kde.
Arts était "officiellement inclus dans kde". Tu connais l'histoire. Ceci dit, c'est mieux que de ne pas être inclus dans KDE.
Puis le problème avec Phonon est : que va supporter KDE ?
Phonon seulement ? => sans issue.
Phonon et Xine et NMM et Gstreamer et alsa ?
KDE avait déjà du mal à supporter Arts. Il faut aussi le reconnaitre qu'il reste beaucoup de boulot à Gnome et Gstreamer. Ceci montre que les ressources du logiciel libre sont insufisantes pour maintenir 50 backends (déjà que pour 3 ou 4 ça sucks).
> il me semble que kde pousse le modèle objet et l'encapsulation le plus loin possible et qu'ils raffolent de ce genre d'outils.
Je répète, si l'encapsulation apporte quelques choses, pourquoi pas.
Il y a un binding de Gstreamer en C++. C'est une encapsulation, ça apporte quelque chose. Les developpeurs C++ sont contents. Les développeurs C++, ce n'est pas 0,1 % des développeurs !
Si KDE veut étendre cette API ou une autre pour ajouter des fonctions qui simplifient la vie des développeurs. Go ! M'enfin Gstreamer ce n'est pas sorcier à utiliser dans un contexte simple.
Si KDE veut le faire pour autre chose que Gstreamer => Go !
Ce que fait KDE, c'est ajouter une API (pas en étendre une pour répondre à un besoin) pour faire ce que tous les backends savent déjà faire (c'est dans la définition de Phonon).
> il s'y trouve même un gnomiste pour défendre cette idée (phonon) et regretter que Gnome n'ait pas fait de même.
C'est très bien !
J'ai peut-être tord, tu as peut-être raison. Tout le monde peut se tromper mais tout le monde à le droit de défendre ses points de vu (c'est une remarque à ceux qui voudraient me "censurer").
Tu peux me trouver un KDEiste qui est contre Phonon ?
> Pour finir, nulle part il n'est, en effet, écrit que les dev seront, couteau sous la gorge, obligés d'utiliser phonon pour une appli externe à kde.
C'est le libre. C'est normal.
Pour une appli KDE :
1- Phonon pour les trucs simples.
2- Xine, GStreamer, NMM, etc pour les trucs un rien compliqués (dès que ce n'est pas dans le plus petit dénominateur commun des backens).
3- Xine, Gstreamer, NMM, etc pour les trucs compliqués.
4- Xine ou Gstreamer ou NMM ou un truc à inventer pour les trucs très spécifiques.
5- Autre chose de mieux que Phonon (le truc par défaut). La liste est longue, voire on ne peut faire plus long, de part la définition de Phonon.
=> Une API supplémentaire (et même pas une extension d'une existant) pour faire ce qu'on sait déjà faire.
=> Beaucoup de cas pour ne pas utiliser Phonon.
=> Donc les efforts seront dispersés (et non mutualisé).
Avec Gnome :
1 Gstreamer pour les trucs simples.
2 Gstreamer pour les trucs compliqués.
3 Xine ou GStreamer ou NMM ou un truc à inventer pour les trucs très spécifiques.
4 Autre chose de mieux que Gstreamer (le truc par défaut). La liste est limitée car Gnome a pris initialement le meilleur framework (du moins selon eux).
=> quelques cas pour ne pas utiliser Gstreamer.
=> Donc les efforts sont concentrés sur Gstreamer (et non dispersé). Ils sont concentrés sur ce qui fait vraiment le boulot, ce qui apporte de la valeur à l'utilisateur, et non sur un wrapper.
KDE ajoute une API et plus de raisons pour les développeurs de se disperser sur 50 backends. Avoir plein de backend sucks ! L'histoire le montre.
Et rien que pour faire des trucs simples, les développeurs doivent maintenir un truc donc le bon fonctionnement dépend de lui-même et de plusieurs backends.
> Ils ne restent donc que fidèles à leur façon de faire avec Phonon.
Non !
Pour les widgets, KDE n'encapsule QUE Qt. Pas Qt et Gtk et Xt etc... et pas en ne fournissant que le plus petit dénominateur commun d'un ensemble de "backends" graphiques.
Il n'y a qu'un "backend" graphique, c'est Qt. Il n'y a qu'un backend vfs, c'est kio, etc. Mais il y aura plusieurs backends multimédia, ce sont NMM, Xine, Gstreamer, etc...
Tu comprends la différence ?
Je n'ai rien contre que KDE encapsule QUE Xine ou autre.
Tu peux considérer que Phonon sera un succès. Si le logiciel libre n'arrive pas faire à un (voire deux) backend qui roxor des ours, il y aura encore 50 backends et il faudra vivre avec.
Si le logiciel libre sucks, Phonon va permettre que ça sucks un peu moins.
Moi, je ne veux pas que le logiciel libre sucks.
Je ne veux pas que le logiciel libre persiste dans une voix qui manifestement ne marche pas. Je n'aime pas ce qui "pousse" à persister dans cette voix qui sucks.
Le choix de KDE est peut-être judicieux. Mais il a des effets de bord non négligeables. Ils faut les reconnaitres et non avoir des oeillères devant les yeux et affirmer que l'encapsulation que fait Phonon est la même que les autres encapsulations faites dans KDE par exemple.
> Libre au dev d'amarok de continuer préférer (je n'en sais rien en fait) xine
Libre, libre, libre !
OK, je le sais, c'est du logiciel libre.
Libre aux développeurs de Gnome de faire comme KDE et pousser dans une voix qui sucks.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
Non.
Ici tu démontres qu'avoir plusieurs backends sucks. Tu démontres aussi que maintenir une interface pour plusieurs backends sucks aussi.
> Il ne s'agit ni plus ni moins que de mutualiser les efforts
Dans l'optique de supporter plusieurs backends !
Mais tu viens de le démontrer, cette démarche sucks et depuis de nombreuses années.
> d'assurer un code qui fonctionne puisqu'il sera officiellement inclus dans kde.
Arts était "officiellement inclus dans kde". Tu connais l'histoire. Ceci dit, c'est mieux que de ne pas être inclus dans KDE.
Puis le problème avec Phonon est : que va supporter KDE ?
Phonon seulement ? => sans issue.
Phonon et Xine et NMM et Gstreamer et alsa ?
KDE avait déjà du mal à supporter Arts. Il faut aussi le reconnaitre qu'il reste beaucoup de boulot à Gnome et Gstreamer. Ceci montre que les ressources du logiciel libre sont insufisantes pour maintenir 50 backends (déjà que pour 3 ou 4 ça sucks).
> il me semble que kde pousse le modèle objet et l'encapsulation le plus loin possible et qu'ils raffolent de ce genre d'outils.
Je répète, si l'encapsulation apporte quelques choses, pourquoi pas.
Il y a un binding de Gstreamer en C++. C'est une encapsulation, ça apporte quelque chose. Les developpeurs C++ sont contents. Les développeurs C++, ce n'est pas 0,1 % des développeurs !
Si KDE veut étendre cette API ou une autre pour ajouter des fonctions qui simplifient la vie des développeurs. Go ! M'enfin Gstreamer ce n'est pas sorcier à utiliser dans un contexte simple.
Si KDE veut le faire pour autre chose que Gstreamer => Go !
Ce que fait KDE, c'est ajouter une API (pas en étendre une pour répondre à un besoin) pour faire ce que tous les backends savent déjà faire (c'est dans la définition de Phonon).
> il s'y trouve même un gnomiste pour défendre cette idée (phonon) et regretter que Gnome n'ait pas fait de même.
C'est très bien !
J'ai peut-être tord, tu as peut-être raison. Tout le monde peut se tromper mais tout le monde à le droit de défendre ses points de vu (c'est une remarque à ceux qui voudraient me "censurer").
Tu peux me trouver un KDEiste qui est contre Phonon ?
> Pour finir, nulle part il n'est, en effet, écrit que les dev seront, couteau sous la gorge, obligés d'utiliser phonon pour une appli externe à kde.
C'est le libre. C'est normal.
Pour une appli KDE :
1- Phonon pour les trucs simples.
2- Xine, GStreamer, NMM, etc pour les trucs un rien compliqués (dès que ce n'est pas dans le plus petit dénominateur commun des backens).
3- Xine, Gstreamer, NMM, etc pour les trucs compliqués.
4- Xine ou Gstreamer ou NMM ou un truc à inventer pour les trucs très spécifiques.
5- Autre chose de mieux que Phonon (le truc par défaut). La liste est longue, voire on ne peut faire plus long, de part la définition de Phonon.
=> Une API supplémentaire (et même pas une extension d'une existant) pour faire ce qu'on sait déjà faire.
=> Beaucoup de cas pour ne pas utiliser Phonon.
=> Donc les efforts seront dispersés (et non mutualisé).
Avec Gnome :
1 Gstreamer pour les trucs simples.
2 Gstreamer pour les trucs compliqués.
3 Xine ou GStreamer ou NMM ou un truc à inventer pour les trucs très spécifiques.
4 Autre chose de mieux que Gstreamer (le truc par défaut). La liste est limitée car Gnome a pris initialement le meilleur framework (du moins selon eux).
=> quelques cas pour ne pas utiliser Gstreamer.
=> Donc les efforts sont concentrés sur Gstreamer (et non dispersé). Ils sont concentrés sur ce qui fait vraiment le boulot, ce qui apporte de la valeur à l'utilisateur, et non sur un wrapper.
KDE ajoute une API et plus de raisons pour les développeurs de se disperser sur 50 backends. Avoir plein de backend sucks ! L'histoire le montre.
Et rien que pour faire des trucs simples, les développeurs doivent maintenir un truc donc le bon fonctionnement dépend de lui-même et de plusieurs backends.
> Ils ne restent donc que fidèles à leur façon de faire avec Phonon.
Non !
Pour les widgets, KDE n'encapsule QUE Qt. Pas Qt et Gtk et Xt etc... et pas en ne fournissant que le plus petit dénominateur commun d'un ensemble de "backends" graphiques.
Il n'y a qu'un "backend" graphique, c'est Qt. Il n'y a qu'un backend vfs, c'est kio, etc. Mais il y aura plusieurs backends multimédia, ce sont NMM, Xine, Gstreamer, etc...
Tu comprends la différence ?
Je n'ai rien contre que KDE encapsule QUE Xine ou autre.
Tu peux considérer que Phonon sera un succès. Si le logiciel libre n'arrive pas faire à un (voire deux) backend qui roxor des ours, il y aura encore 50 backends et il faudra vivre avec.
Si le logiciel libre sucks, Phonon va permettre que ça sucks un peu moins.
Moi, je ne veux pas que le logiciel libre sucks.
Je ne veux pas que le logiciel libre persiste dans une voix qui manifestement ne marche pas. Je n'aime pas ce qui "pousse" à persister dans cette voix qui sucks.
Le choix de KDE est peut-être judicieux. Mais il a des effets de bord non négligeables. Ils faut les reconnaitres et non avoir des oeillères devant les yeux et affirmer que l'encapsulation que fait Phonon est la même que les autres encapsulations faites dans KDE par exemple.
> Libre au dev d'amarok de continuer préférer (je n'en sais rien en fait) xine
Libre, libre, libre !
OK, je le sais, c'est du logiciel libre.
Libre aux développeurs de Gnome de faire comme KDE et pousser dans une voix qui sucks.