> Je sais, et c'est le mode par défaut de Fedora, mais pas de toutes les distro
C'est le mode par défaut de Gnome.
> et quand je disais qu'ils en reviennent, c'est de l'avis d'une bonne partie des grandes têtes derrière Gnome.
L'histoire jugera.
> KDE n'a pas les ressources requises pour participer au développement de ton beau gstreamer
Je répète encore, ce qui m'énerve dans Phonon, ce n'est pas spécifiquement que KDE ne prenne pas Gstreamer, mais que Phonon fait une abstraction pour plusieurs frameworks et évite de se concentrer sur le vrai problème (c-à-d améliorer le framework multimédia, qu'il soit Gstreamer ou Xine ou autre).
Lis mes commentaires plus haut.
> KDE n'a pas les ressources requises pour participer
Mais KDE a les ressources pour faire Phonon...
De faire du support pour Phonon/Xine, Phonon/Gstreamer, Phonon/NMM, ...
De suivre les modifications d'ABI de Xine, Gstreamer, NMM, etc pour réajuster Phonon.
D'avoir des développeurs qui connaissent l'API de phonon, de Xine, de Gstreamer, de NMM, etc...
C'est ça qui est abhérant dans le choix de Phonon. Tous les explications de KDE ne tiennent pas la route dès qu'on y réfléchi plus de 2 secondes.
> Gnome a Red Hat, Novell (qui a acquis Ximian), des aides pour les HIG de Sun et pas mal de bugfix, ils ont eu Eazel pour créer Nautilus, niveau marketing ils sont bien servis avec Ubuntu dernièrement..
C'est vrai et ça aide. Indéniablement.
> niveau marketing ils sont bien servis avec Ubuntu dernièrement..
Kde à Kubuntu (mais peut-être pas le support de Canonical).
> Alors ouais, KDE ne participe pas directement à la création de ton framework multimédia, et ?
Sois gentil, remplaces "ton framework multimédia" par "son framework multimédia".
C'est du libre, libre à qui veut de participer. C'est claire.
Il n'a jamais été demandé à KDE de participé à Gstreamer s'ils ne veulent pas. Simplement on (plus précisément ici moi) s'interroge sur le choix fait par KDE.
En effet, Phonon est une perte de ressources (ressources KDE selon toi si précieuses, j'en suis d'accord) sans plus-value pour l'utilisateur.
Il y a de bonnes raisons à faire une encapsulation. Par exemple avoir une API triviale pour les actions simples et gérer les changements d'API. Pourquoi pas.
Mais Phonon va le faire pour plusieurs backends.
Et tout ça pour offrir le plus petit dénominateur commun des backends.
Ces ressources précieuses n'apporterons rien au logiciel libre. Sans compter le problème du support : Quand un programme déconne, c'est qui le fautif : L'appli, Phonon, ou l'un des 3 ou 4 backends supportés ?
Faudra aussi un système pour que le périphérique donne ses caractéristiques à Phonon et au backend, etc.
D'ailleur il y a déjà NMM qui "porte" son backend pour Phonon.
KDE a des soucis légitimes de stabilité d'API. Très bien, voyons ça, trouvons une solution. Sur ma bécane j'ai gstreamer 0.8 et 0.10. Ca marche. Sous Gnome il y a esound (compatibilié sur toute la branche 2.x) et gstreamer (un peu de blinding-edge). Si esound tourne et qu'il n'y a pas dmix d'alsa, gstreamer utiliser esound. Le minimum de ressource a été utilisé et on a le maximum de souplesse. Même en pronant une ABI stable, Gnome ne s'est pas enfermé.
On peut trouver des solutions sans sortir ce "machin" de Phonon.
Imaginons que KDE choisisse Xine (ce qui n'empêche pas chaque application d'utiliser NMM ou autre). Xine profite du support de KDE et Xine s'améliore. Forcément Gstreamer s'améliore aussi (via les corrections de ffmpeg, via une veille sur Xine, etc). Et si Xine surpasse Gstreamer, ben Gnome passera à Xine pour le bien de ses utilisateurs et on félicitera KDE pour la pertinance de son choix et Xine (voire KDE) pour la qualité du travaille. Si ça arrive durant la branche Gnome 3.X, il y aura dans Gnome 3.x, Gstreamer (compatibilité pour le bonheur des développeurs), et Xine (pour le bonheur des utilisateurs) comme il y a aujourd'hui esound et Gstreamer.
Effectivement celà est possible aussi avec Phonon. Mais avec Phonon on bouffe des ressources pour rien.
Un des principes de Phonon, est de considérer que ça merde. Les frameworks merdent car ils changent d'API, ils merdent car il faut plusieurs backends pour satisfaire l'utilisateur ou le développeur.
Je préfère que des ressources soient affectées à corriger cette merde, qu'à vivre avec.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
C'est le mode par défaut de Gnome.
> et quand je disais qu'ils en reviennent, c'est de l'avis d'une bonne partie des grandes têtes derrière Gnome.
L'histoire jugera.
> KDE n'a pas les ressources requises pour participer au développement de ton beau gstreamer
Je répète encore, ce qui m'énerve dans Phonon, ce n'est pas spécifiquement que KDE ne prenne pas Gstreamer, mais que Phonon fait une abstraction pour plusieurs frameworks et évite de se concentrer sur le vrai problème (c-à-d améliorer le framework multimédia, qu'il soit Gstreamer ou Xine ou autre).
Lis mes commentaires plus haut.
> KDE n'a pas les ressources requises pour participer
Mais KDE a les ressources pour faire Phonon...
De faire du support pour Phonon/Xine, Phonon/Gstreamer, Phonon/NMM, ...
De suivre les modifications d'ABI de Xine, Gstreamer, NMM, etc pour réajuster Phonon.
D'avoir des développeurs qui connaissent l'API de phonon, de Xine, de Gstreamer, de NMM, etc...
C'est ça qui est abhérant dans le choix de Phonon. Tous les explications de KDE ne tiennent pas la route dès qu'on y réfléchi plus de 2 secondes.
> Gnome a Red Hat, Novell (qui a acquis Ximian), des aides pour les HIG de Sun et pas mal de bugfix, ils ont eu Eazel pour créer Nautilus, niveau marketing ils sont bien servis avec Ubuntu dernièrement..
C'est vrai et ça aide. Indéniablement.
> niveau marketing ils sont bien servis avec Ubuntu dernièrement..
Kde à Kubuntu (mais peut-être pas le support de Canonical).
> Alors ouais, KDE ne participe pas directement à la création de ton framework multimédia, et ?
Sois gentil, remplaces "ton framework multimédia" par "son framework multimédia".
C'est du libre, libre à qui veut de participer. C'est claire.
Il n'a jamais été demandé à KDE de participé à Gstreamer s'ils ne veulent pas. Simplement on (plus précisément ici moi) s'interroge sur le choix fait par KDE.
En effet, Phonon est une perte de ressources (ressources KDE selon toi si précieuses, j'en suis d'accord) sans plus-value pour l'utilisateur.
Il y a de bonnes raisons à faire une encapsulation. Par exemple avoir une API triviale pour les actions simples et gérer les changements d'API. Pourquoi pas.
Mais Phonon va le faire pour plusieurs backends.
Et tout ça pour offrir le plus petit dénominateur commun des backends.
Ces ressources précieuses n'apporterons rien au logiciel libre. Sans compter le problème du support : Quand un programme déconne, c'est qui le fautif : L'appli, Phonon, ou l'un des 3 ou 4 backends supportés ?
Faudra aussi un système pour que le périphérique donne ses caractéristiques à Phonon et au backend, etc.
D'ailleur il y a déjà NMM qui "porte" son backend pour Phonon.
KDE a des soucis légitimes de stabilité d'API. Très bien, voyons ça, trouvons une solution. Sur ma bécane j'ai gstreamer 0.8 et 0.10. Ca marche. Sous Gnome il y a esound (compatibilié sur toute la branche 2.x) et gstreamer (un peu de blinding-edge). Si esound tourne et qu'il n'y a pas dmix d'alsa, gstreamer utiliser esound. Le minimum de ressource a été utilisé et on a le maximum de souplesse. Même en pronant une ABI stable, Gnome ne s'est pas enfermé.
On peut trouver des solutions sans sortir ce "machin" de Phonon.
Imaginons que KDE choisisse Xine (ce qui n'empêche pas chaque application d'utiliser NMM ou autre). Xine profite du support de KDE et Xine s'améliore. Forcément Gstreamer s'améliore aussi (via les corrections de ffmpeg, via une veille sur Xine, etc). Et si Xine surpasse Gstreamer, ben Gnome passera à Xine pour le bien de ses utilisateurs et on félicitera KDE pour la pertinance de son choix et Xine (voire KDE) pour la qualité du travaille. Si ça arrive durant la branche Gnome 3.X, il y aura dans Gnome 3.x, Gstreamer (compatibilité pour le bonheur des développeurs), et Xine (pour le bonheur des utilisateurs) comme il y a aujourd'hui esound et Gstreamer.
Effectivement celà est possible aussi avec Phonon. Mais avec Phonon on bouffe des ressources pour rien.
Un des principes de Phonon, est de considérer que ça merde. Les frameworks merdent car ils changent d'API, ils merdent car il faut plusieurs backends pour satisfaire l'utilisateur ou le développeur.
Je préfère que des ressources soient affectées à corriger cette merde, qu'à vivre avec.