Chez moi (Debian amd64) : GLib = 934K, QtCore = 2,6M. Mais il faut ajouter GObject parce que même si on peut utiliser GLib sans GObject
Que tu comptes ou pas GObject, GLib reste 2 à 3 fois plus petit que QtCore. Dans des systèmes embarqués, ça n'a rien de négligeable (d'ailleurs, tu peux compiler QtCore sans le support de la GLib pour cette raison).
Mais bon, ça n'élimine pas le problème du C++ et de son ABI de merde.
Il n'y a aucune dépendance circulaire entre GLib et QtCore, les deux sont implémentés indépendamment l'une de l'autre et n'utilise pas du tout l'autre.
Mes confuses, on ne s'est pas compris, c'est juste qu'exiger que la Glib ait un requirement vers QtCore parce que QtCore a une dépendance vers GLib, c'est juste stupide.
Et Xine ? Et mplayer/ffmpeg ? Sérieusement, tu dis n'importe quoi là
Ce ne sont PAS des frameworks multimédias ! (du moins pas aussi complet que GStreamer dans le cas de Xine)
Xine a un champs d'action beaucoup plus réduit que GStreamer, il est clairement passé en mode maintenance et son architecture peu modulaire n'aide pas à sa diffusion.
MPlayer est un gloubiboulga qui fait lecteur (certes, il le fait très bien!)
FFmpeg une collection de codecs et de petits programmes. KDE a développé Phonon parce que GStreamer n'offrait pas suffisamment de garantie de stabilité d'API/ABI (GStreamer 0.10 est sortie en 2006, et on peut installer en parallèle plusieurs versions), FFmpeg c'est pire, bien pire, encore bien plus pire que ça.
comme PulseAudio, ça a mis des plombes à marcher correctement pour des utilisations basiques
PA va se trainer pendant combien de temps, les casseroles d'Ubuntu ? PA a été intégré dans Fedora 8 par son mainteneur et ça a fonctionné correctement dès le PREMIER jour, Mandriva, SuSE l'ont fait dans les 6 mois qui suivent sans problèmes majeurs.
Les branquignols de Canonical l'ont intégré comme des bourrins dans une version LTS sans prendre le temps de tester ni même contacter Lennart et après, c'est de la faute de PA ?
si on regarde les news du projet GStreamer depuis sa création, le développeur s'est rendu plusieurs fois au GUADEC (jamais à l'Akademy)
Est-ce que quelqu'un a offert de sponsoriser le voyage du développeur à aKademy ? Non.
À l'origine, c'était un projet universitaire et il s'est écoulé deux ans entre la première release publique et le rapprochement avec GNOME.
même sur la page wikipedia anglaise de GStreamer a une boite GNOME en bas, le citant parmi les technologies GNOME
Idem pour la page Qt qui le cite comme une technologie KDE, dois-je en conclure que KDE développe Qt ?
En parlant de Qt, c'est un peu agaçant de dire que KDE fait plus d'efforts que GNOME en terme d'intéropérabilité alors que rien n'est plus faux (pour autant GNOME n'en fait pas plus, on est bien d'accord).
La plupart des initiatives d'intéropérabilité viennent de Trolltech puis Nokia pour diverses raisons: ils vendent un framework cross-platform qui doit s'intégrer le mieux possible à la plateforme native GNOME compris. Les gens de KDE sont pas plus altruistes que ceux de GNOME.
Tu veux dire "faire comme les devs GNOME" ?
en l'occurrence s/GNOME/KDE/ ! Je pense qu'il y a un gros problème de communication.
Au début, t'as un mec qui bute régulièrement sur un problème commun à tous, selon son background, il aura une approche différente:
GNOME: je propose une spécification avec un début d'implémentation, on discute, je modifie mon implémentation, si tout le monde est d'accord, c'est tacitement accepté.
KDE: je propose une implémentation fonctionnelle voire intégré à une version sortie, et on fait une spécification autour puis c'est explicitement accepté.
Tu rajoutes la mauvaise foi coutumière des geeks libristes et ça donne un mélange explosif.
Donc forcément, les gens de GNOME voient les gens de KDE comme passifs et renfermés et les gens de KDE ceux de GNOME comme autoritaires. C'est un peu le problème de fd.o qui n'est pas vraiment un organisme de normalisation mais avant tout un forum de discussion, il faudrait éventuellement formaliser le processus pour gommer ce genre d'incompréhension.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par GeneralZod . En réponse au journal Gnome vs Canonical: l'avis de Aaron Seigo. Évalué à 1. Dernière modification le 10 mars 2011 à 13:40.
Que tu comptes ou pas GObject, GLib reste 2 à 3 fois plus petit que QtCore. Dans des systèmes embarqués, ça n'a rien de négligeable (d'ailleurs, tu peux compiler QtCore sans le support de la GLib pour cette raison).
Mais bon, ça n'élimine pas le problème du C++ et de son ABI de merde.
Mes confuses, on ne s'est pas compris, c'est juste qu'exiger que la Glib ait un requirement vers QtCore parce que QtCore a une dépendance vers GLib, c'est juste stupide.
Ce ne sont PAS des frameworks multimédias ! (du moins pas aussi complet que GStreamer dans le cas de Xine)
PA va se trainer pendant combien de temps, les casseroles d'Ubuntu ? PA a été intégré dans Fedora 8 par son mainteneur et ça a fonctionné correctement dès le PREMIER jour, Mandriva, SuSE l'ont fait dans les 6 mois qui suivent sans problèmes majeurs.
Les branquignols de Canonical l'ont intégré comme des bourrins dans une version LTS sans prendre le temps de tester ni même contacter Lennart et après, c'est de la faute de PA ?
Est-ce que quelqu'un a offert de sponsoriser le voyage du développeur à aKademy ? Non.
À l'origine, c'était un projet universitaire et il s'est écoulé deux ans entre la première release publique et le rapprochement avec GNOME.
Idem pour la page Qt qui le cite comme une technologie KDE, dois-je en conclure que KDE développe Qt ?
En parlant de Qt, c'est un peu agaçant de dire que KDE fait plus d'efforts que GNOME en terme d'intéropérabilité alors que rien n'est plus faux (pour autant GNOME n'en fait pas plus, on est bien d'accord).
La plupart des initiatives d'intéropérabilité viennent de Trolltech puis Nokia pour diverses raisons: ils vendent un framework cross-platform qui doit s'intégrer le mieux possible à la plateforme native GNOME compris. Les gens de KDE sont pas plus altruistes que ceux de GNOME.
en l'occurrence s/GNOME/KDE/ ! Je pense qu'il y a un gros problème de communication.
Au début, t'as un mec qui bute régulièrement sur un problème commun à tous, selon son background, il aura une approche différente: GNOME: je propose une spécification avec un début d'implémentation, on discute, je modifie mon implémentation, si tout le monde est d'accord, c'est tacitement accepté.
KDE: je propose une implémentation fonctionnelle voire intégré à une version sortie, et on fait une spécification autour puis c'est explicitement accepté. Tu rajoutes la mauvaise foi coutumière des geeks libristes et ça donne un mélange explosif.
Donc forcément, les gens de GNOME voient les gens de KDE comme passifs et renfermés et les gens de KDE ceux de GNOME comme autoritaires. C'est un peu le problème de fd.o qui n'est pas vraiment un organisme de normalisation mais avant tout un forum de discussion, il faudrait éventuellement formaliser le processus pour gommer ce genre d'incompréhension.