Voilà que ça recommence. Une lecture de planetkde et de kde-multimedia n'est pas inutile avant d'affirmer des choses pareilles. Enfin, plongeons-y :
GStreamer dépend de GLib, bibliothèque que d'aucuns trouvent faire double emploi avec les fonctionnalités objet du C++
Pas du tout, tu confonds GLib et GObject
GOjbect fait doublon avec les fonctionnalités objet du C++
Glib c'est une bibliothèque qui implémente les listes chaînées et autres, qui est petite stable et très bien documentée, et qui se retrouverait en pratique reprogrammée en moins bien et plus boguée dans chaque projet programmé en C.
Or si tu étais à Akademy, Trolltech y a dt que la philosophie de QT c'est de pouvoir accéder à toute une panoplie de bibliothèques programmées en C et de lui donner une API agréable en C++ (une API soignée étant au programmeur ce qu'une IHM soignée étant à l'utilisateur). Gstreamer rentre donc parfaitement dans la philosophie QT/KDE (une fois que les bindings adéquats sont réalisés. ça tombe bien, Scott Wheeler de JuK s'est proposé pour les maintenir)
La politique de KDE est d'utiliser le moins de bibliothèques extérieures possibles car cela fragilise notre processus de développement.
1) Cf paragraphe précédent. Regarde combien de bibliothèques extérieures en C QT/KDE utilisent.
2) Pas de chance, glib est déjà dans KDE, ironie du sort, par le biais de Arts
[^] # Re: Le son dans 3.4
Posté par jmfayard . En réponse au journal Le son sous KDE (3.)4. Évalué à 4.
GStreamer dépend de GLib, bibliothèque que d'aucuns trouvent faire double emploi avec les fonctionnalités objet du C++
Pas du tout, tu confonds GLib et GObject
GOjbect fait doublon avec les fonctionnalités objet du C++
Glib c'est une bibliothèque qui implémente les listes chaînées et autres, qui est petite stable et très bien documentée, et qui se retrouverait en pratique reprogrammée en moins bien et plus boguée dans chaque projet programmé en C.
Or si tu étais à Akademy, Trolltech y a dt que la philosophie de QT c'est de pouvoir accéder à toute une panoplie de bibliothèques programmées en C et de lui donner une API agréable en C++ (une API soignée étant au programmeur ce qu'une IHM soignée étant à l'utilisateur). Gstreamer rentre donc parfaitement dans la philosophie QT/KDE (une fois que les bindings adéquats sont réalisés. ça tombe bien, Scott Wheeler de JuK s'est proposé pour les maintenir)
La politique de KDE est d'utiliser le moins de bibliothèques extérieures possibles car cela fragilise notre processus de développement.
1) Cf paragraphe précédent. Regarde combien de bibliothèques extérieures en C QT/KDE utilisent.
2) Pas de chance, glib est déjà dans KDE, ironie du sort, par le biais de Arts