> - utilisation de phonon comme framework multimedia
Je viens de me renseigner sur Phonon. C'est un peu tard, je sais. Mais je n'utilise pas KDE.
Déjà, ce n'est pas un framework, c'est limite une coquille vide.
Ne faisons pas dans la dentelle : Quelle connerie...
C'est du KDE tout krashé^Wcraché. Faut que ça pète plus haut que son cul.
Il y a quelques temps, on nous rabachait que KDE avait au moins 3 ans d'avance sur Gnome, que C++ roxor et C puxor, etc...
Puis KDE jurait que jamais il n'utiliserait Dbus car c'est une émanation du maléfique Gnome, que ça pue et que Dcop a au moins 10 années lumières d'avance.
Puis KDE a tortillé du cul pour savoir s'il prenait ou non Gstreamer car Arts était agonisant.
Quand j'ai vu que KDE "adoptait" Dbus, je me suis dit que KDE était enfin "raisonnable", qu'il prendrait Gstreamer, et que tout va pour le mieux dans le meilleur des mondes. Que la jonction des forces de KDE, Gnome et Gstreamer aboutirait à une solution multimédia qui roxe des ours. Car oui, Gstreamer a besoin des forces de KDE. Pas pour le meilleur de Gnome mais pour le meilleurs des utilisateurs de Gnome, de KDE, d'xfce, etc.
Car en définitive, l'utilisateur final en a rien à foutre de savoir que c'est Gstreamer ou tartanpion qui lit sa video. S'il est utilisateur de KDE, il veut un bureau typé KDE car c'est ce qui lui convient le mieux. Que KDE utilise Gstreamer ou Dbus, ne va en rien changer le typage du bureau.
Finalement, qu'à choisi KDE pour le multimédia ?
Phonon.
Pour bien résumer, on peut dire que ça ne sert à rien.
Je vais ajouter un peu d'eau dans mon vin et dire que c'est une abstraction. Il peut y avoir de bonnes raisons de le faire. Par exemple pour avoir une meilleure intégration dans KDE (utiliser kio, etc).
Mais ces bonnes raisons n'ont pas été les motivations premières de Phonon. Phonon est une abstraction au-dessus DES toolkits multimédia. Une sorte de méta-toolkit ou je ne sais quoi. Ca doit permettre à KDE de faire du multimédia indépendament du toolkit utilisé.
Sur le papier, c'est mignon. Dans la pratique c'est une autre histoire. Faut se limiter au plus petit dénominateur commun. Si ce n'est pas satisfaisant, Phonon dupliquera des fonctionnalités de Gstreamer ou autre. Il y aura aussi les applis qui vont courcircuiter l'API limité de Phonon pour attaquer directement, qui Gsteamer, qui NMM, etc...
Quelles sont les raisons avancées pour Phonon (liste non exhautive) :
* Eviter la mésaventure de Arts. C'est-à-dire ne pas être dépendand de la maintenance d'un toolkit (ou framework). Naze comme raison. C'est aussi arrivé à Gnome avec esd. Arts était limité, il fallait autre chose. Même si Arts était maintenu, son API était à revoir. Ca peut arriver avec Gstreamer et ça peut aussi arriver avec l'API de Phonon. Je ne me trompe en disant que maintenant KDE est dépendant d'un toolkit multimédia (comme avant mais en plus peut-être de plusieurs toolkits si les applis se mettent à taper dans l'API de tel ou tel toolkit car Phonon est limité) ET de Phonon. Si Phonon n'est plus maintenu, qu'es-ce qu'il se passe ? Certe Phonon est un projet pour KDE. Mais Arts aussi était un projet pour KDE ! Brèf, même problème qu'avec Arts.
* Pouvoir choisir entre plusieurs toolkits, et donc choisir le meilleur. L'intention est louable. Mais autant choisir tout de suite le meilleur et travailler avec ce dernier pour en tirer profis au-lieu de se limiter au plus petit dénominateur commun.
Ce qui est désagréable dans cette raison avancée par KDE, c'est qu'en gros on dirait que KDE ne veut pas s'impliquer dans les toolkits multimédia. L'attitude est condescendante. Type "je veux le meilleur sans rien foutre, car je le vaux bien". Gstreamer est sur http://freedesktop.org/ pour travailler avec les développeurs des bureaux et des applications !
Enfin, une abstraction pour faire une abstraction est de la connerie. Car c'est finalement ce qui va arriver à Phonon. Au final, Phonon sera utiliser dans 99,9 % des cas toujours avec le même toolkit.
Havoc Pennington avait fait un très bon papier sur ça à propos de Cairo. L'argumentaire a été convaincant et il n'y a pas d'abstraction dans gtk/gdk pour attaquer Cairo. L'API Gdk est conservée (pour compatibilité) et toute l'API de Cairo est disponible.
Il n'est pas demandé aux développeurs d'applications Gnome ou Gtk de se limiter à une partie de l'API de Cairo (par exemple via Gdk). Alors que du côté de KDE, il va être demandé de se limiter à Phonon (sinon Phonon perd de son intérêt).
* La portabilité. C'est à mourir de rire. C'est le boulot même des toolkits.
Si ces raisons sont importantes au yeux des développeurs de KDE, il devrait faire une abstraction par rapport au toolkit graphique. On ne sait jamais, si Qt n'est plus maintenu, s'il y a un autre meilleur toolkit, ou si Qt n'existe pas sur une plate-forme (avant il n'y avait pas de Qt GPL pour Windows !!).
L'attitude de Gnome est toute autre. Gnome se lie fortement à un projet, ça motive les développeurs du projet, ça motive les développeurs Gnome à participer à ce projet. C'est du gagnant-gagnant et ça ne peut marcher que s'il n'y a pas de défiance. Mais pourquoi il y en aurait ? C'est bien meilleur pour le logiciel libre que de faire une abstraction en pariant sur la division puis sur un rapide positionnement opportuniste. Ce choix "politique" de Gnome ne le rend pas dépendant. On est dans le logiciel libre, Gnome peut forcker si nécessaire. Gnome peut toujours aller voir ailleurs (comme ils l'ont fait en passant d'esd à Gstreamer).
Donc pourquoi cette défiance des développeurs de KDE ? Pourquoi ce choix tordu ?
Simplement car Gstreamer est associé à Gnome. C'est mon avis.
A mon sens, c'est la vraie raison. Si par exemple Xine était meilleur que Gstreamer, KDE serait parti avec Xine sans faire ce truc tordu qu'est Phonon. Il ne resterait qu'à dire "bonne chance KDE/Xine et va savoir si un jour Gnome ne va pas rejoindre KDE pour utiliser Xine".
Ce Phonon est grandiosement stupide, car les "vrais" raisons de son existance, l'utilisateur final en a rien à foutre.
Le logiciel libre ne gagne rien avec ce type d'attitude (parier sur la division). Ni en image, ni en qualité logiciel.
# Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -8.
Je viens de me renseigner sur Phonon. C'est un peu tard, je sais. Mais je n'utilise pas KDE.
Déjà, ce n'est pas un framework, c'est limite une coquille vide.
Ne faisons pas dans la dentelle : Quelle connerie...
C'est du KDE tout krashé^Wcraché. Faut que ça pète plus haut que son cul.
Il y a quelques temps, on nous rabachait que KDE avait au moins 3 ans d'avance sur Gnome, que C++ roxor et C puxor, etc...
Puis KDE jurait que jamais il n'utiliserait Dbus car c'est une émanation du maléfique Gnome, que ça pue et que Dcop a au moins 10 années lumières d'avance.
Puis KDE a tortillé du cul pour savoir s'il prenait ou non Gstreamer car Arts était agonisant.
Quand j'ai vu que KDE "adoptait" Dbus, je me suis dit que KDE était enfin "raisonnable", qu'il prendrait Gstreamer, et que tout va pour le mieux dans le meilleur des mondes. Que la jonction des forces de KDE, Gnome et Gstreamer aboutirait à une solution multimédia qui roxe des ours. Car oui, Gstreamer a besoin des forces de KDE. Pas pour le meilleur de Gnome mais pour le meilleurs des utilisateurs de Gnome, de KDE, d'xfce, etc.
Car en définitive, l'utilisateur final en a rien à foutre de savoir que c'est Gstreamer ou tartanpion qui lit sa video. S'il est utilisateur de KDE, il veut un bureau typé KDE car c'est ce qui lui convient le mieux. Que KDE utilise Gstreamer ou Dbus, ne va en rien changer le typage du bureau.
Finalement, qu'à choisi KDE pour le multimédia ?
Phonon.
Pour bien résumer, on peut dire que ça ne sert à rien.
Je vais ajouter un peu d'eau dans mon vin et dire que c'est une abstraction. Il peut y avoir de bonnes raisons de le faire. Par exemple pour avoir une meilleure intégration dans KDE (utiliser kio, etc).
Mais ces bonnes raisons n'ont pas été les motivations premières de Phonon. Phonon est une abstraction au-dessus DES toolkits multimédia. Une sorte de méta-toolkit ou je ne sais quoi. Ca doit permettre à KDE de faire du multimédia indépendament du toolkit utilisé.
Sur le papier, c'est mignon. Dans la pratique c'est une autre histoire. Faut se limiter au plus petit dénominateur commun. Si ce n'est pas satisfaisant, Phonon dupliquera des fonctionnalités de Gstreamer ou autre. Il y aura aussi les applis qui vont courcircuiter l'API limité de Phonon pour attaquer directement, qui Gsteamer, qui NMM, etc...
Quelles sont les raisons avancées pour Phonon (liste non exhautive) :
* Eviter la mésaventure de Arts. C'est-à-dire ne pas être dépendand de la maintenance d'un toolkit (ou framework). Naze comme raison. C'est aussi arrivé à Gnome avec esd. Arts était limité, il fallait autre chose. Même si Arts était maintenu, son API était à revoir. Ca peut arriver avec Gstreamer et ça peut aussi arriver avec l'API de Phonon. Je ne me trompe en disant que maintenant KDE est dépendant d'un toolkit multimédia (comme avant mais en plus peut-être de plusieurs toolkits si les applis se mettent à taper dans l'API de tel ou tel toolkit car Phonon est limité) ET de Phonon. Si Phonon n'est plus maintenu, qu'es-ce qu'il se passe ? Certe Phonon est un projet pour KDE. Mais Arts aussi était un projet pour KDE ! Brèf, même problème qu'avec Arts.
* Pouvoir choisir entre plusieurs toolkits, et donc choisir le meilleur. L'intention est louable. Mais autant choisir tout de suite le meilleur et travailler avec ce dernier pour en tirer profis au-lieu de se limiter au plus petit dénominateur commun.
Ce qui est désagréable dans cette raison avancée par KDE, c'est qu'en gros on dirait que KDE ne veut pas s'impliquer dans les toolkits multimédia. L'attitude est condescendante. Type "je veux le meilleur sans rien foutre, car je le vaux bien". Gstreamer est sur http://freedesktop.org/ pour travailler avec les développeurs des bureaux et des applications !
Enfin, une abstraction pour faire une abstraction est de la connerie. Car c'est finalement ce qui va arriver à Phonon. Au final, Phonon sera utiliser dans 99,9 % des cas toujours avec le même toolkit.
Havoc Pennington avait fait un très bon papier sur ça à propos de Cairo. L'argumentaire a été convaincant et il n'y a pas d'abstraction dans gtk/gdk pour attaquer Cairo. L'API Gdk est conservée (pour compatibilité) et toute l'API de Cairo est disponible.
Il n'est pas demandé aux développeurs d'applications Gnome ou Gtk de se limiter à une partie de l'API de Cairo (par exemple via Gdk). Alors que du côté de KDE, il va être demandé de se limiter à Phonon (sinon Phonon perd de son intérêt).
* La portabilité. C'est à mourir de rire. C'est le boulot même des toolkits.
Si ces raisons sont importantes au yeux des développeurs de KDE, il devrait faire une abstraction par rapport au toolkit graphique. On ne sait jamais, si Qt n'est plus maintenu, s'il y a un autre meilleur toolkit, ou si Qt n'existe pas sur une plate-forme (avant il n'y avait pas de Qt GPL pour Windows !!).
L'attitude de Gnome est toute autre. Gnome se lie fortement à un projet, ça motive les développeurs du projet, ça motive les développeurs Gnome à participer à ce projet. C'est du gagnant-gagnant et ça ne peut marcher que s'il n'y a pas de défiance. Mais pourquoi il y en aurait ? C'est bien meilleur pour le logiciel libre que de faire une abstraction en pariant sur la division puis sur un rapide positionnement opportuniste. Ce choix "politique" de Gnome ne le rend pas dépendant. On est dans le logiciel libre, Gnome peut forcker si nécessaire. Gnome peut toujours aller voir ailleurs (comme ils l'ont fait en passant d'esd à Gstreamer).
Donc pourquoi cette défiance des développeurs de KDE ? Pourquoi ce choix tordu ?
Simplement car Gstreamer est associé à Gnome. C'est mon avis.
A mon sens, c'est la vraie raison. Si par exemple Xine était meilleur que Gstreamer, KDE serait parti avec Xine sans faire ce truc tordu qu'est Phonon. Il ne resterait qu'à dire "bonne chance KDE/Xine et va savoir si un jour Gnome ne va pas rejoindre KDE pour utiliser Xine".
Ce Phonon est grandiosement stupide, car les "vrais" raisons de son existance, l'utilisateur final en a rien à foutre.
Le logiciel libre ne gagne rien avec ce type d'attitude (parier sur la division). Ni en image, ni en qualité logiciel.