l'évolution de KDE sur plusieures années (la durée de vie de KDE 4) est contrainte au plus petit dénominateur commun des backends et ils se donnent beaucoup de boulot.
Encore une fois, le but de Phonon n'est pas d'implémenter tous les backend.
Si certains ont envie d'implémenter des nouveaux backend, qu'ils le fassent, mais il ne me semblent pas qu'il y en aura une tripotée d'officiellement supportée.
Oui. Mais il faut aussi se demander s'il n'est pas plus pertinant d'adapter les logiciels aux dernières évolutions. Dans le domaine du desktop où l'utilisateur veut du "dernier cri" et où les développeurs se font fort de répondre aux attentes des utilisateurs, ce n'est pas à sous-estimer. Surtout aussi que les développeurs du libre aiment utiliser le "dernier cri" et non "trainer" avec du "has been".
Le rapport avec la choucroute ? Tu crois vraiment que les devs de kwin par exemple ont besoin du dernier cri pour lire un son quand tu réduis ta fenêtre ?
Sans compter qui s'il s'agit d'une technologie qui améliore une fonctionnalité (genre le 5.1 sur la lecture d'un son), elle peut être intégrée à Phonon (et du coup, toutes les appli l'auront, sans que les développeurs changent une ligne, merveilleux, non ?).
Pour un backend multimédia, c'est une poignée d'application pour un service qui n'est pas critique (mais important).
Au contraire, il s'agit de toutes les applications KDE, sauf les applis multimédias. Je ne pense pas qu'on puisse parler d'une poignée.
Allez, je le répète encore une fois : on parle ici des applications qui ont des besoins simples en multimédia. Ces besoins ont-ils évolués pendant les 5 dernières années ? Si oui, j'aimerai bien savoir en quoi.
Ta comparaison avec le noyau 2.6 ne tient pas, justement parce que ce qu'ils cassent, c'est la compatiblité avec les applications qui dépendent intimement du noyau.
Pour te montrer que la stabilité de ABI n'est pas si importante que ça, et notament dans le logiciel libre, je te donne des exemples. Les binaires de FC5 ne marchent pas sur FC4 et inférieur. Pratiquement personne ne l'a remarqué !
Pour FC6, ça sera encore comme ça !
Il ne sagit pas de une ou deux applis, mais de toute les applis livrées par FC et FE.
Il me semble, bien que je ne sois pas sûr à 100%, qu'il s'agit de l'inverse.
Un binaire compilé sur KDE 3.4 doit toujours marcher avec KDE 3.5.
Considères aussi Xorg. Xorg casse les binaires (côté driver) pour faire avancer les choses et 2 ou 3 semaines après tout est rentré dans l'ordre pour le bénéfice de tous. Ce n'est pas un point faible du libre/Xorg mais un point fort (malheureusement pas toujours compris).
Les drivers, c'est quand même quelque chose d'intimement lié à X.org, ce qui n'est pas le cas des appli qui utiliseront Phonon vers une api multimédia.
J'ai quand même pas envie d'apprendre 5 framework multimédia et de maintenir à jour juste pour lire un son quand j'affiche mes mickeys qui clignotent.
C'est très juste. Mais je ne crois pas que le logiciel libre y gagne en considérant que c'est la règle.
Il faut respecter cette liberté, non considérer que c'est la règle.
J'essaie justement de t'expliquer qu'il y gagne, puisque :
on est sûr que pour toutes appli qui veut jouer un son, si elle s'appuie sur un seul framework, il y aura un utilisateur pour prendre la tête aux devs parce qu'il aime pas ce backend.
Partant de ce principe, toutes les appli, si elles veulent satisfaire les utilisateurs, doivent implémenter plusieurs backend. Toujours pour, rappelons-le, lire un son quand elles affichent des mickeys qui clignotent.
Ne crois-tu pas qu'il peut être intéressant d'écrire un wrapper qui permette de lire un son avec choix du backend ?
Crois-tu vraiment qu'un utilisateur va demander aux devs d'une appli classique d'ajouter de nouvelles fonctionnalités sur le son ? Genre le support du wma42 DRM21 inside ?
Ici tu te trompes. Pourquoi, pour l'utilisateur, demander à Phonon de changer de backend si le but de Phonon est d'avoir la même chose quelque soit le backend ?
Parce qu'il y a la petite-fille de la tante du cousin de ma mère qui développe le backend plopiniou. Elle est très jolie, donc je préfère utiliser le backend plopiniou.
Des raisons connes pour pouvoir préférer un backend à un autre à fonctionnalité égale, il y en a des milliards.
Croire que l'utilisateur ne va pas vouloir imposer le sien, c'est au moins aussi idiot que croire que l'utilisateur ne va pas demander à kwin plus que lire des fichiers ogg lors d'un évènement.
Et si ça change quelque chose, pourquoi Phonon encapsule des backends qui offrent de "piètres" prestations ?
Parce qu'il y a des utilisateurs qui préfèrent celui-là, pour une raison X ou Y, recevable ou non.
Tu ne serais pas en train de faire la confusion avec des facilité du bureau qui sauvegarde des préférences utilisateurs du style "mon navigateur préféré", "mon client mail préféré", "mon lecteur dvd préféré" ? Ce dernier pouvant lancer un lecteur qui utilise Phonon ou Xine ou ...
Je veux que toutes les appli qui jouent du son, de kwin à kopete en passant par kttsmgr utilisent le même backend de lecture.
Alors certes, on peut imaginer que toutes les applications lisent une préférence dans un fichier commun et qu'elles implémentent toutes le support de différents backend.
Ou bien on peut imaginer une lib qui wrappe les fonctionnalités vers différents backend, et qui lise son propre fichier de conf.
[^] # Re: Phonon
Posté par Jean-Philippe Garcia Ballester . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 7.
Encore une fois, le but de Phonon n'est pas d'implémenter tous les backend.
Si certains ont envie d'implémenter des nouveaux backend, qu'ils le fassent, mais il ne me semblent pas qu'il y en aura une tripotée d'officiellement supportée.
Oui. Mais il faut aussi se demander s'il n'est pas plus pertinant d'adapter les logiciels aux dernières évolutions. Dans le domaine du desktop où l'utilisateur veut du "dernier cri" et où les développeurs se font fort de répondre aux attentes des utilisateurs, ce n'est pas à sous-estimer. Surtout aussi que les développeurs du libre aiment utiliser le "dernier cri" et non "trainer" avec du "has been".
Le rapport avec la choucroute ? Tu crois vraiment que les devs de kwin par exemple ont besoin du dernier cri pour lire un son quand tu réduis ta fenêtre ?
Sans compter qui s'il s'agit d'une technologie qui améliore une fonctionnalité (genre le 5.1 sur la lecture d'un son), elle peut être intégrée à Phonon (et du coup, toutes les appli l'auront, sans que les développeurs changent une ligne, merveilleux, non ?).
Pour un backend multimédia, c'est une poignée d'application pour un service qui n'est pas critique (mais important).
Au contraire, il s'agit de toutes les applications KDE, sauf les applis multimédias. Je ne pense pas qu'on puisse parler d'une poignée.
Allez, je le répète encore une fois : on parle ici des applications qui ont des besoins simples en multimédia. Ces besoins ont-ils évolués pendant les 5 dernières années ? Si oui, j'aimerai bien savoir en quoi.
Ta comparaison avec le noyau 2.6 ne tient pas, justement parce que ce qu'ils cassent, c'est la compatiblité avec les applications qui dépendent intimement du noyau.
Pour te montrer que la stabilité de ABI n'est pas si importante que ça, et notament dans le logiciel libre, je te donne des exemples. Les binaires de FC5 ne marchent pas sur FC4 et inférieur. Pratiquement personne ne l'a remarqué !
Pour FC6, ça sera encore comme ça !
Il ne sagit pas de une ou deux applis, mais de toute les applis livrées par FC et FE.
Il me semble, bien que je ne sois pas sûr à 100%, qu'il s'agit de l'inverse.
Un binaire compilé sur KDE 3.4 doit toujours marcher avec KDE 3.5.
Considères aussi Xorg. Xorg casse les binaires (côté driver) pour faire avancer les choses et 2 ou 3 semaines après tout est rentré dans l'ordre pour le bénéfice de tous. Ce n'est pas un point faible du libre/Xorg mais un point fort (malheureusement pas toujours compris).
Les drivers, c'est quand même quelque chose d'intimement lié à X.org, ce qui n'est pas le cas des appli qui utiliseront Phonon vers une api multimédia.
J'ai quand même pas envie d'apprendre 5 framework multimédia et de maintenir à jour juste pour lire un son quand j'affiche mes mickeys qui clignotent.
C'est très juste. Mais je ne crois pas que le logiciel libre y gagne en considérant que c'est la règle.
Il faut respecter cette liberté, non considérer que c'est la règle.
J'essaie justement de t'expliquer qu'il y gagne, puisque :
on est sûr que pour toutes appli qui veut jouer un son, si elle s'appuie sur un seul framework, il y aura un utilisateur pour prendre la tête aux devs parce qu'il aime pas ce backend.
Partant de ce principe, toutes les appli, si elles veulent satisfaire les utilisateurs, doivent implémenter plusieurs backend. Toujours pour, rappelons-le, lire un son quand elles affichent des mickeys qui clignotent.
Ne crois-tu pas qu'il peut être intéressant d'écrire un wrapper qui permette de lire un son avec choix du backend ?
Crois-tu vraiment qu'un utilisateur va demander aux devs d'une appli classique d'ajouter de nouvelles fonctionnalités sur le son ? Genre le support du wma42 DRM21 inside ?
Ici tu te trompes. Pourquoi, pour l'utilisateur, demander à Phonon de changer de backend si le but de Phonon est d'avoir la même chose quelque soit le backend ?
Parce qu'il y a la petite-fille de la tante du cousin de ma mère qui développe le backend plopiniou. Elle est très jolie, donc je préfère utiliser le backend plopiniou.
Des raisons connes pour pouvoir préférer un backend à un autre à fonctionnalité égale, il y en a des milliards.
Croire que l'utilisateur ne va pas vouloir imposer le sien, c'est au moins aussi idiot que croire que l'utilisateur ne va pas demander à kwin plus que lire des fichiers ogg lors d'un évènement.
Et si ça change quelque chose, pourquoi Phonon encapsule des backends qui offrent de "piètres" prestations ?
Parce qu'il y a des utilisateurs qui préfèrent celui-là, pour une raison X ou Y, recevable ou non.
Tu ne serais pas en train de faire la confusion avec des facilité du bureau qui sauvegarde des préférences utilisateurs du style "mon navigateur préféré", "mon client mail préféré", "mon lecteur dvd préféré" ? Ce dernier pouvant lancer un lecteur qui utilise Phonon ou Xine ou ...
Je veux que toutes les appli qui jouent du son, de kwin à kopete en passant par kttsmgr utilisent le même backend de lecture.
Alors certes, on peut imaginer que toutes les applications lisent une préférence dans un fichier commun et qu'elles implémentent toutes le support de différents backend.
Ou bien on peut imaginer une lib qui wrappe les fonctionnalités vers différents backend, et qui lise son propre fichier de conf.