Tu te focalise sur les backends et sur le point de vue utilisateur, c'est pour ça que tu trouves ça idiot. Le truc c'est d'éviter au développeur qui code une appli de gestion de rendez vous, par exemple, de se casser la tête s'il a besoin d'animer son appli (genre message personnalisé, "fais gaffe, ton train part dans dix minutes !", ou que sais-je).
Actuellement, le dev en question doit d'abord choisir un framework pas forcément intégré à kde et en assimiler la doc, ensuite coder en espérant que tous les utilisateurs disposent de la lib.
L'avantage de phonon, c'est que là le dev n'a pas à se poser de question, c'est intégré à kde. Donc il utilise gentiment l'api prévue (hint: l'avantage sur utiliser xine en dur c'est l'api plus simple et l'absence de dépendance dure), et c'est kde qui se débrouille avec les moyens du bord pour que le son sorte par les enceintes, avec probablement peu de pertes de performance vu que sur le fond c'est juste un wrapper. Réutilisation (en utilisant un backend tout fait), et mutualisation du code (via le wrapper, au lieu de forcer les gens à mettre de grosses boilerplates pour utiliser une api plus complexe), c'est exactement ce que tu prône non ?
Si phonon n'utilisait pas de backends mais se débrouillait pour sortir le son tout seul tu n'aurais probablement rien contre :)
Le fait que phonon se réduise au plus petit dénominateur commun n'est pas génant vu son objectif (faire des trucs multimédia pouet pouet *simples* facilement et de manière portable). Évidemment qu'une appli de MAO n'utilisera pas phonon, mais une interface plus élaborée genre jack.
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 10.
Actuellement, le dev en question doit d'abord choisir un framework pas forcément intégré à kde et en assimiler la doc, ensuite coder en espérant que tous les utilisateurs disposent de la lib.
L'avantage de phonon, c'est que là le dev n'a pas à se poser de question, c'est intégré à kde. Donc il utilise gentiment l'api prévue (hint: l'avantage sur utiliser xine en dur c'est l'api plus simple et l'absence de dépendance dure), et c'est kde qui se débrouille avec les moyens du bord pour que le son sorte par les enceintes, avec probablement peu de pertes de performance vu que sur le fond c'est juste un wrapper. Réutilisation (en utilisant un backend tout fait), et mutualisation du code (via le wrapper, au lieu de forcer les gens à mettre de grosses boilerplates pour utiliser une api plus complexe), c'est exactement ce que tu prône non ?
Si phonon n'utilisait pas de backends mais se débrouillait pour sortir le son tout seul tu n'aurais probablement rien contre :)
Le fait que phonon se réduise au plus petit dénominateur commun n'est pas génant vu son objectif (faire des trucs multimédia pouet pouet *simples* facilement et de manière portable). Évidemment qu'une appli de MAO n'utilisera pas phonon, mais une interface plus élaborée genre jack.
Tu trouves toujours ça aberrant ?