> 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.
Sacré défit...
> 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".
Fichtre, comme Gnome. Une appli Gnome 2.0 tourne sous n'importe qu'elle Gnome 2.x.
Et oui, il y a toujours esound avec Gnome 2.14 et il y sera là temps que Gnome 3.0 ne sera pas sorti.
Gstreamer ne fait pas encore parti de la "gnome platform". Il est dans "gnome desktop". Mais il sera dans la "gnome platform" pour Gnome 3.
Gnome est découpé en :
- gnome platform
- gnome desktop
- gnome binding
- gnome admin
> 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.
Ben comme X11, comme Qt, comme la libc, comme dbus, comme libxml2, etc...
Tu m'expliques pourquoi KDE pinaille avec le framework media et pas avec le reste ?
Pourtant c'est exactement le même problème.
> Une solution serait de forker une de ces libs si l'ABI upstream venait à changer, ce qui serait pire que tout.
Pourtant ça se fait. Regardes les distributions qui garantisse la compatibilité ABI durant le support.
> Une solution serait de forker une de ces libs si l'ABI upstream venait à changer
Une autre solution est aussi l'encapsulation (NB : c'est un bon motif d'encapsulation).
Que fait KDE : ils encapsulent plusieurs backends.
KDE devra gérer les changement d'ABI de plusieurs backends.
Où est l'avantage ?
Mistère...
Gnome ne fait ça que pour *un* backend. Pour Gnome 2.x, c'est esound. A partir de Gnome 3.0, ça sera Gstreamer et pour toute la vie de Gnome 3.x (On peut tabler sur 5 ans par analogie avec Gnome 2.x).
> 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.
Ben applique le même raisonnement pour les autres librairies que KDE utilise mais ne développe pas.
> Râles-tu parce que Xine a des backends alsa, OSS, arts, esd, ou que sais-je d'autre ?
Que est le rapport ?
Xine (idem pour gstreamer) subit Linux (OSS et alsa (qui n'avait pas dmix)), KDE (arts), et Gnome (esound).
Aujourd'hui sous Gnome avec Gstreamer : Ben comme alsa utilise dmix, Xine a uniquement besoin d'alsa et se fout de la présence ou non de Gstreamer.
Pourquoi tu veux que Xine maintienne les vieilleries ?
Je ne comprend pas.
La meilleur solution, c'est alsa. Donc on prend alsa et le reste on l'oubli. On ne s'amuse pas à garder 50 trucs plus ou moins bon car on a la trouille qu'alsa change d'API, ou ne soit plus maintenu.
> Pourtant, OSS est vachement limité !
Je n'utilise pas OSS.
> Et le jour où un super moteur, apportant toutes les garanties nécessaires à KDE verra le jour
KDE ne fait rien pour que ça arrive. KDE attend que ça arrive.
Gnome et Gstreamer se bouge le cul pour que ça arrive.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -3.
Sacré défit...
> 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".
Fichtre, comme Gnome. Une appli Gnome 2.0 tourne sous n'importe qu'elle Gnome 2.x.
Et oui, il y a toujours esound avec Gnome 2.14 et il y sera là temps que Gnome 3.0 ne sera pas sorti.
Gstreamer ne fait pas encore parti de la "gnome platform". Il est dans "gnome desktop". Mais il sera dans la "gnome platform" pour Gnome 3.
Gnome est découpé en :
- gnome platform
- gnome desktop
- gnome binding
- gnome admin
Gnome platform : ftp://ftp.gnome.org/pub/GNOME/platform/
> 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.
Ben comme X11, comme Qt, comme la libc, comme dbus, comme libxml2, etc...
Tu m'expliques pourquoi KDE pinaille avec le framework media et pas avec le reste ?
Pourtant c'est exactement le même problème.
> Une solution serait de forker une de ces libs si l'ABI upstream venait à changer, ce qui serait pire que tout.
Pourtant ça se fait. Regardes les distributions qui garantisse la compatibilité ABI durant le support.
> Une solution serait de forker une de ces libs si l'ABI upstream venait à changer
Une autre solution est aussi l'encapsulation (NB : c'est un bon motif d'encapsulation).
Que fait KDE : ils encapsulent plusieurs backends.
KDE devra gérer les changement d'ABI de plusieurs backends.
Où est l'avantage ?
Mistère...
Gnome ne fait ça que pour *un* backend. Pour Gnome 2.x, c'est esound. A partir de Gnome 3.0, ça sera Gstreamer et pour toute la vie de Gnome 3.x (On peut tabler sur 5 ans par analogie avec Gnome 2.x).
> 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.
Ben applique le même raisonnement pour les autres librairies que KDE utilise mais ne développe pas.
> Râles-tu parce que Xine a des backends alsa, OSS, arts, esd, ou que sais-je d'autre ?
Que est le rapport ?
Xine (idem pour gstreamer) subit Linux (OSS et alsa (qui n'avait pas dmix)), KDE (arts), et Gnome (esound).
Aujourd'hui sous Gnome avec Gstreamer : Ben comme alsa utilise dmix, Xine a uniquement besoin d'alsa et se fout de la présence ou non de Gstreamer.
Pourquoi tu veux que Xine maintienne les vieilleries ?
Je ne comprend pas.
La meilleur solution, c'est alsa. Donc on prend alsa et le reste on l'oubli. On ne s'amuse pas à garder 50 trucs plus ou moins bon car on a la trouille qu'alsa change d'API, ou ne soit plus maintenu.
> Pourtant, OSS est vachement limité !
Je n'utilise pas OSS.
> Et le jour où un super moteur, apportant toutes les garanties nécessaires à KDE verra le jour
KDE ne fait rien pour que ça arrive. KDE attend que ça arrive.
Gnome et Gstreamer se bouge le cul pour que ça arrive.