"Et le jour où il veut faire un peu plus compliqué que ce que permet l'API de Phonon ? Par exemple à la demande des utilisateurs ou simplement car il en a envis.
Il peut demander à Phonon d'étendre l'API. Mais Phonon va peut-être dire "non" car ils veulent conserver une API "serrée" ou car un backend supporté par Phonon ne permet pas la fonctionnalité."
On se tue à te dire que *non* il ne demandera pas une extension à phonon. Il apprendra à se servir d'une boître à outils plus conséquente (et ce ne sera, la plupart du temps, pas nécessaire).
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.
Il ne s'agit ni plus ni moins que de mutualiser les efforts (au niveau de kde bien sur) et d'assurer un code qui fonctionne puisqu'il sera officiellement inclus dans kde.
"Faire des trucs simple avec Gstreamer, c'est l'affaire de 10 ou 20 lignes. Un développeur qui ne sait pas gérer ça, n'est pas un développeur."
Toujours les mêmes sympatiques humilité et nuance.
Je t'engage à relire les commentaires sur le blog de Aaron Seigo, 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.
"Beaucoup de développeurs vont se dire "je vais mettre 20 lignes au lieu de 10 afin de ne pas être bloqué par l'API minimaliste de Phonon"."
Comment le sais-tu ? As-tu déjà développé pour Kde ? Raisonnes-tu comme eux ?
Vu de l'extérieur (j'utilise Gnome et je ne suis pas un programmeur émérite), 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. Ils ne restent donc que fidèles à leur façon de faire avec 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. Libre au dev d'amarok de continuer préférer (je n'en sais rien en fait) xine mais je pense que la plupart de ceux n'ayant pas des besoins spécifiques (seulement lire des fichiers audio et vidéo) ne se priveront pas de cette possibilité.
À suivre donc...
[^] # Re: Phonon
Posté par mats . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 8.
Il peut demander à Phonon d'étendre l'API. Mais Phonon va peut-être dire "non" car ils veulent conserver une API "serrée" ou car un backend supporté par Phonon ne permet pas la fonctionnalité."
On se tue à te dire que *non* il ne demandera pas une extension à phonon. Il apprendra à se servir d'une boître à outils plus conséquente (et ce ne sera, la plupart du temps, pas nécessaire).
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.
Il ne s'agit ni plus ni moins que de mutualiser les efforts (au niveau de kde bien sur) et d'assurer un code qui fonctionne puisqu'il sera officiellement inclus dans kde.
"Faire des trucs simple avec Gstreamer, c'est l'affaire de 10 ou 20 lignes. Un développeur qui ne sait pas gérer ça, n'est pas un développeur."
Toujours les mêmes sympatiques humilité et nuance.
Je t'engage à relire les commentaires sur le blog de Aaron Seigo, 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.
"Beaucoup de développeurs vont se dire "je vais mettre 20 lignes au lieu de 10 afin de ne pas être bloqué par l'API minimaliste de Phonon"."
Comment le sais-tu ? As-tu déjà développé pour Kde ? Raisonnes-tu comme eux ?
Vu de l'extérieur (j'utilise Gnome et je ne suis pas un programmeur émérite), 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. Ils ne restent donc que fidèles à leur façon de faire avec 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. Libre au dev d'amarok de continuer préférer (je n'en sais rien en fait) xine mais je pense que la plupart de ceux n'ayant pas des besoins spécifiques (seulement lire des fichiers audio et vidéo) ne se priveront pas de cette possibilité.
À suivre donc...