> J'ai deja explique pourquoi pour des raisons techniques, ca posait des problemes: il faut traduire toutes les structures de donnees echangees entre glib et KDE et ca a un cout CPU.
Rire dans la salle :-)
KDE est cerné de lib en C.
C'est mieux si c'est déjà en C++ (quoi que...).
Gstreamer n'est pas une librairie ala libc où une fonction (par exemple strcmp()) peut-être appelé 2 000 000 de fois en une seconde. L'appli fait gst_play() et ça reste dans gstreamer. Il n'y a pas d'aller-retour entre l'appli en C++ et gstreamer qui pénalisent la lecture d'une video. Il doit bien y avoir des "détails" comme ce qui indique la position dans le flux, etc mais ça doit peser moins de 0,002 % de charge cpu.
Pour être honnète, je trouve gonflé que certains KDE-xxx (xxx = developpeurs|fans|utilisateurs...) critiquent la glib dès qu'elle est utilisée dans le cadre de KDE.
Je ne veux pas dire que la glib est parfaite.
Mais la glib avec son modèle objet, permet à gstreamer (et Gnome) d'être C++ friendly et donc KDE friendly.
KDE n'est pas C friendly (évidemment y en a un qui va bondir pour indiquer un wrap qt ou kde, mais ces wrap sont immondes (oui oui, j'ai déjà regardé)).
KDE peut utiliser des bibliothèques C, et plus particulièrement les libs qui utilisent glib et qui peuvent être orienté objet (comme gstreamer). Alors profitez en.
Que ceci ne t'empêche pas de faire des propositions pour améliorer les performances de la glib.
> Toute dependance supplementaire n'est _jamais_ bienvenue.
Tu veux dire quoi ?
Que lorsque la dépendance à libvorbis a été ajoutée, elle n'était pas la bienvenue ?
Que tout proposition pour virer la dépendance à Qt est la bienvenue ?
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par 007 . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 3.
Rire dans la salle :-)
KDE est cerné de lib en C.
C'est mieux si c'est déjà en C++ (quoi que...).
Gstreamer n'est pas une librairie ala libc où une fonction (par exemple strcmp()) peut-être appelé 2 000 000 de fois en une seconde. L'appli fait gst_play() et ça reste dans gstreamer. Il n'y a pas d'aller-retour entre l'appli en C++ et gstreamer qui pénalisent la lecture d'une video. Il doit bien y avoir des "détails" comme ce qui indique la position dans le flux, etc mais ça doit peser moins de 0,002 % de charge cpu.
Pour être honnète, je trouve gonflé que certains KDE-xxx (xxx = developpeurs|fans|utilisateurs...) critiquent la glib dès qu'elle est utilisée dans le cadre de KDE.
Je ne veux pas dire que la glib est parfaite.
Mais la glib avec son modèle objet, permet à gstreamer (et Gnome) d'être C++ friendly et donc KDE friendly.
KDE n'est pas C friendly (évidemment y en a un qui va bondir pour indiquer un wrap qt ou kde, mais ces wrap sont immondes (oui oui, j'ai déjà regardé)).
KDE peut utiliser des bibliothèques C, et plus particulièrement les libs qui utilisent glib et qui peuvent être orienté objet (comme gstreamer). Alors profitez en.
Que ceci ne t'empêche pas de faire des propositions pour améliorer les performances de la glib.
> Toute dependance supplementaire n'est _jamais_ bienvenue.
Tu veux dire quoi ?
Que lorsque la dépendance à libvorbis a été ajoutée, elle n'était pas la bienvenue ?
Que tout proposition pour virer la dépendance à Qt est la bienvenue ?
PS : KDE dépend déjà de la glib (via arts).