1 : KDE a besoin d'offrir un moyen simple, présent dans les libs au coeur de toute installation KDE, de jouer des sons. Le support peut parfaitement être super-basique, mais il faut quelque chose.
2 : KDE a décidé, et ce depuis très longtemps (le tout début ?) que tout au long de la vie d'une version majeure, la compatibilité binaire était conservée dans les libs "core".
Il s'ensuit que KDE ne peut pas considérer GStreamer, ni même xine, comme interface par défaut de toute installation KDE. Ils n'ont pas autorité sur le développement et les cycles de release de ces bibliothèques. Une solution serait de forker une de ces libs si l'ABI upstream venait à changer, ce qui serait pire que tout. Et là, tu ne serais plus tout seul à crier, crois-moi.
Se dire que xine ou GStreamer seront incapables de garder une ABI compatible sur les deux ou trois (ou quatre, si KDE 5 se fait attendre) années à venir, ce n'est pas de la défiance, c'est du simple bon sens.
Dans KDE 4, les notifications sonores passeront sans doute par Phonon. Peut-être également les "prévisualisations" de fichiers audio. Mais je suis persuadé que mon Amarok et mon Kaffeine utiliseront toujours Xine... sauf si le "plus petit dénominateur commun" qui te fait si peur est capable de les remplacer sans perte de fonctionnalités. Soit Phonon est petit, et est là pour toute application qui a besoin de fonctions basiques ; soit Phonon est grand, et encapsule Xine de manière étendue et avec une interface propre à KDE. Dans les deux cas, il comble un besoin.
Et avec tout ça, je ne comprends toujours pas ce que tu lui reproche. L'API de Phonon n'est pas développée à partir du PPCD des libs existantes, elle est faite selon les besoins des développeurs. Qu'il y ait un ou plusieurs backends ne change rien à l'histoire. Râles-tu parce que Xine a des backends alsa, OSS, arts, esd, ou que sais-je d'autre ? Pourtant, OSS est vachement limité !
Et le jour où un super moteur, apportant toutes les garanties nécessaires à KDE verra le jour, Phonon sera joyeusement mis à la poubelle. Qui sait, ce moteur sera peut-être même développé en collaboration Gnome/KDE, sur les bases de GStreamer ou xine ?
[^] # Re: Phonon
Posté par Amand Tihon (site web personnel) . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 10.
1 : KDE a besoin d'offrir un moyen simple, présent dans les libs au coeur de toute installation KDE, de jouer des sons. Le support peut parfaitement être super-basique, mais il faut quelque chose.
2 : KDE a décidé, et ce depuis très longtemps (le tout début ?) que tout au long de la vie d'une version majeure, la compatibilité binaire était conservée dans les libs "core".
Il s'ensuit que KDE ne peut pas considérer GStreamer, ni même xine, comme interface par défaut de toute installation KDE. Ils n'ont pas autorité sur le développement et les cycles de release de ces bibliothèques. Une solution serait de forker une de ces libs si l'ABI upstream venait à changer, ce qui serait pire que tout. Et là, tu ne serais plus tout seul à crier, crois-moi.
Se dire que xine ou GStreamer seront incapables de garder une ABI compatible sur les deux ou trois (ou quatre, si KDE 5 se fait attendre) années à venir, ce n'est pas de la défiance, c'est du simple bon sens.
Dans KDE 4, les notifications sonores passeront sans doute par Phonon. Peut-être également les "prévisualisations" de fichiers audio. Mais je suis persuadé que mon Amarok et mon Kaffeine utiliseront toujours Xine... sauf si le "plus petit dénominateur commun" qui te fait si peur est capable de les remplacer sans perte de fonctionnalités. Soit Phonon est petit, et est là pour toute application qui a besoin de fonctions basiques ; soit Phonon est grand, et encapsule Xine de manière étendue et avec une interface propre à KDE. Dans les deux cas, il comble un besoin.
Et avec tout ça, je ne comprends toujours pas ce que tu lui reproche. L'API de Phonon n'est pas développée à partir du PPCD des libs existantes, elle est faite selon les besoins des développeurs. Qu'il y ait un ou plusieurs backends ne change rien à l'histoire. Râles-tu parce que Xine a des backends alsa, OSS, arts, esd, ou que sais-je d'autre ? Pourtant, OSS est vachement limité !
Et le jour où un super moteur, apportant toutes les garanties nécessaires à KDE verra le jour, Phonon sera joyeusement mis à la poubelle. Qui sait, ce moteur sera peut-être même développé en collaboration Gnome/KDE, sur les bases de GStreamer ou xine ?