Vu que c'est un journal public et qu'il ne va pas disparaître avant deux semaines, je sens que le troll ci-dessus a encore de belles heures devant lui. Ça me désole.
J'avais évité de mettre le pied dedans vu que l'on tourne en rond et que finalement, je ne sais plus vraiment ce que cherche à démontrer clearstream, mais je vais essayer de faire un petit récapitulatif. (Attention, je me mets au C++/Qt mais je ne connais pas tous les boyaux de KDE/Qt, donc corrigez moi si je me trompe. Qui plus est, pas la peine de me traiter de fanboy KDE, car j'ai utilisé KDE et Gnome en alternance pendant quelques années avant de me poser chez KDE pour le moment. Je laisserai aussi le côté "KDE dénigre Gnome" et "KDE c'est ils jouent perso" de côté pour recentrer sur la technique.)
- Les développements de KDE et de QT sont intimement liés, avec une version majeure de QT précédent une version majeure de KDE. Il faudra que je me renseigne plus en avant sur ces liens ;)
- QT est la librairie de base des programmateurs KDE (avec kdelibs), qui permet (entre autres) d'avoir une API/ABI stable et unifiée au dessus de plein de libs (Xlib, libpng, libxml, ...) [ réponse à http://linuxfr.org/comments/745544.html#745544 ]
- Malheureusement, rien n'est prévu dans QT4 pour le son (vu que c'est à la base un toolkit graphique quand même :p). L'idée est venue de faire l'encapsulation d'un framework multimedia pour avoir les mêmes avantages que QT pour les graphismes : stabilité d'API/ABI et syntaxe objet unifiée avec le reste (et portabilité aussi si possible).
- Vient alors la question du framework à encapsuler. L'avantage de l'encapsulation est qu'on peut fournir la même API en passant par n'importe quel backend s'il est supporté. Le fait de supporter plusieurs backends est un plus, pas le but recherché. Qui plus est, ça arrange ceux qui ont des mauvais souvenirs avec arts ;)
- Non, ce n'est pas une somme de travail immense de rajouter le support d'un backend, c'est écrire quelques fonctions de quelques lignes. Si l'API d'un backend change, il n'y a qu'à modifier ces fonctions, recompiler phonon et tout va bien. J'imagine même que la plupart des plugins de gestion des backends seront maintenus par un gars de l'équipe de dev du backend concerné.
- Le "plus petit dénominateur commun" de gst/xine/mplayer est quand même énorme : lire des vidéos, des sons, streaming, mixer, equalizer, effets vidéo, ... tout le nécessaire pour la quasi totalité des applications desktop (knotify, amarok, kaffeine, kmix, krec, ...), on ne parle pas de MAO et de temps réel là. Pour la MAO, il vaut mieux de toute façon passer par jack que gst/xine.
- Comme dit plus haut, c'est du "sucre" pour les développeurs, rien qui n'impacte directement luce et henry, à part des soucis en moins dans amarok quand gstreamer change d'API ou quand xine ne veut pas marcher avec dmix.
J'espère n'avoir pas dit trop de bêtises. Maintenant, clearstream, qu'est-ce qui te révolte tant ?
# Au secours
Posté par xavier66 . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 9.
J'avais évité de mettre le pied dedans vu que l'on tourne en rond et que finalement, je ne sais plus vraiment ce que cherche à démontrer clearstream, mais je vais essayer de faire un petit récapitulatif. (Attention, je me mets au C++/Qt mais je ne connais pas tous les boyaux de KDE/Qt, donc corrigez moi si je me trompe. Qui plus est, pas la peine de me traiter de fanboy KDE, car j'ai utilisé KDE et Gnome en alternance pendant quelques années avant de me poser chez KDE pour le moment. Je laisserai aussi le côté "KDE dénigre Gnome" et "KDE c'est ils jouent perso" de côté pour recentrer sur la technique.)
- Les développements de KDE et de QT sont intimement liés, avec une version majeure de QT précédent une version majeure de KDE. Il faudra que je me renseigne plus en avant sur ces liens ;)
- QT est la librairie de base des programmateurs KDE (avec kdelibs), qui permet (entre autres) d'avoir une API/ABI stable et unifiée au dessus de plein de libs (Xlib, libpng, libxml, ...) [ réponse à http://linuxfr.org/comments/745544.html#745544 ]
- Malheureusement, rien n'est prévu dans QT4 pour le son (vu que c'est à la base un toolkit graphique quand même :p). L'idée est venue de faire l'encapsulation d'un framework multimedia pour avoir les mêmes avantages que QT pour les graphismes : stabilité d'API/ABI et syntaxe objet unifiée avec le reste (et portabilité aussi si possible).
- Vient alors la question du framework à encapsuler. L'avantage de l'encapsulation est qu'on peut fournir la même API en passant par n'importe quel backend s'il est supporté. Le fait de supporter plusieurs backends est un plus, pas le but recherché. Qui plus est, ça arrange ceux qui ont des mauvais souvenirs avec arts ;)
- Non, ce n'est pas une somme de travail immense de rajouter le support d'un backend, c'est écrire quelques fonctions de quelques lignes. Si l'API d'un backend change, il n'y a qu'à modifier ces fonctions, recompiler phonon et tout va bien. J'imagine même que la plupart des plugins de gestion des backends seront maintenus par un gars de l'équipe de dev du backend concerné.
- Le "plus petit dénominateur commun" de gst/xine/mplayer est quand même énorme : lire des vidéos, des sons, streaming, mixer, equalizer, effets vidéo, ... tout le nécessaire pour la quasi totalité des applications desktop (knotify, amarok, kaffeine, kmix, krec, ...), on ne parle pas de MAO et de temps réel là. Pour la MAO, il vaut mieux de toute façon passer par jack que gst/xine.
- Comme dit plus haut, c'est du "sucre" pour les développeurs, rien qui n'impacte directement luce et henry, à part des soucis en moins dans amarok quand gstreamer change d'API ou quand xine ne veut pas marcher avec dmix.
J'espère n'avoir pas dit trop de bêtises. Maintenant, clearstream, qu'est-ce qui te révolte tant ?