Pour ne pas avoir à dépendre de gstreamer (ou autre) pendant toute la durée de vie de KDE 4.x comme ça a été le cas avec aRts.
Ca ne fait que reporter le problème non ? Il dépendront de phonon et plus de arts. Et en plus phonon dépendera de tout les moteurs (si une modif est casse leur truc faudra bien réagir)
Pour ne pas avoir à porter gstreamer (ou autre) sur toutes les plateformes que KDE 4.x supportera (windows, osx...).
Je connais mieux gstreamer, c'est pour ça que j'en parle, mais il me semble que c'est une lib assez portable déjà. Pourquoi bosser sur leur truc plutot que de contribuer à gstreamer pour la rendre plus portable ? (vrai question, pas une critique)
Pour simplifier la vie aux développeurs des applications KDE qui n'ont pas à apprendre une API complètement différente de ce dont ils ont l'habitude.
Ils ont déjà l'habitude de phonon ? De plus j'ai lu qu'avec gstreamer, pour des besoins de base, c'est rapide à coder, et vite fonctionnel.
Ce que je ne comprend pas c'est qu'il parle d'abstraction alors que ces moteur la fond déjà (enfin je crois). Ensuite il parle de besoin de base et que les applis poussées ou spécialisées utiliserons directement le moteur de leur choix. Si c'est pour du son de base, je reviens sur gstreamer qui à la réputation d'être rapide à coder et efficace.
Je comprend toujours pas leur motivation :). Vu la difficulté et le temps que ca demande de faire un truc comme ça il doivent avoir de bonne raison (autre que le mauvais souvenir d'un démon de son) pour le faire.
[^] # Re: Question
Posté par François (site web personnel) . En réponse à la dépêche Annonce du projet Phonon. Évalué à 2.
Ca ne fait que reporter le problème non ? Il dépendront de phonon et plus de arts. Et en plus phonon dépendera de tout les moteurs (si une modif est casse leur truc faudra bien réagir)
Pour ne pas avoir à porter gstreamer (ou autre) sur toutes les plateformes que KDE 4.x supportera (windows, osx...).
Je connais mieux gstreamer, c'est pour ça que j'en parle, mais il me semble que c'est une lib assez portable déjà. Pourquoi bosser sur leur truc plutot que de contribuer à gstreamer pour la rendre plus portable ? (vrai question, pas une critique)
Pour simplifier la vie aux développeurs des applications KDE qui n'ont pas à apprendre une API complètement différente de ce dont ils ont l'habitude.
Ils ont déjà l'habitude de phonon ? De plus j'ai lu qu'avec gstreamer, pour des besoins de base, c'est rapide à coder, et vite fonctionnel.
Ce que je ne comprend pas c'est qu'il parle d'abstraction alors que ces moteur la fond déjà (enfin je crois). Ensuite il parle de besoin de base et que les applis poussées ou spécialisées utiliserons directement le moteur de leur choix. Si c'est pour du son de base, je reviens sur gstreamer qui à la réputation d'être rapide à coder et efficace.
Je comprend toujours pas leur motivation :). Vu la difficulté et le temps que ca demande de faire un truc comme ça il doivent avoir de bonne raison (autre que le mauvais souvenir d'un démon de son) pour le faire.