Ah, je realise qu'il y en effet une grosse confusion de ma part entre glib et gobject. C'est plutot gobject que je critique dans l'absolu.
> Pourquoi est-ce que KDE rajoute ça (ça étant au moins les signaux) par
> dessus un langage qui ne le supporte pas, autant faire du C# plutôt que de réinventer la roue ?
C'est trolltech qui rajoute ca. En effet, ca peux sembler un bon argument. Cependant, au moment ou Trolltech a choisi d'ajouter des signaux, des slots et de proprietes aux objets C++, il n'y avait aucun equivalent sur le marche, a part vaguement java, mais qui conservait des performances catastrophiques.
Ca fait une grosse difference avec Gnome qui a choisi entre plusieurs langages objets: C, C++, objective C, et qui a finalement opte pour le moins objet de tous.
> Disons que KDE a besoin d'un framework multimédia, il n'en existe pas utilisant QT nativement, donc arrêtez de faire les difficiles aussi « ah oui, on veut bien de votre framework multimédia, mais bon, on pose nos conditions »
C'est en etant tres selectif dans les technologies qu'il utilise qu'un projet etablit les bases technologiques de son succes. Ca vaut pour KDE (DCOP aui lieu de orbit), pour Gnome (orbit au lieu de mico), pour mozilla (un framework complet javascript ecrit pendant 3 ans avant de faire quoi que ce soit) et pour les autres.
On peut ne pas etre d'accord avec les choix faits, mais tu ne peux pas reprocher a un projet de choisir ses technologies soigneusement. Surtout quand il s'est deja plante une fois par le passe.
> Le pire, c'est que si le framework en question réécrivait à partir de 0 ce qui est contenu dans la glib, il y aurait moins d'opposition...
Ca ne ressort pas dans mes posts, mais personellement, je suis pour l'utilisation de la glib pour tout projet en C. Parce que si tu ne l'utilises pas, tu vas finir par la recoder tout de meme.
> > Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder
> Plus rapide et plus efficace ? En tout cas pour les trucs de base (héritage, ...) je vois pas trop en quoi ça serait plus rapide à l'exécution...
Je pensais a gobject. Pour la glib, je ne pense pas qu'il y aie de difference. D'ailleurs, quand on regarde sous les QList, on voit des grosses optimisations typiques du C (et vas-y que je te malloc tout ca et que je me deplace avec des additions sur les pointeurs).
> Cf le code de xdgmime qui a été écrit sans utiliser la glib entre autre en espérant que les gars de kde accepteraient de le réutiliser
Un naif qui s'est fait avoir. Honnetement, je pense que le consensus dans KDE est d'avoir du code propre. Apres, ca donnes des interpretations differentes sur les moyens d'arriver a ce but. Ce qui est sur, c'est qu'un mec qui recode glib a la main sera encore moins bien vu (en tout cas pour moi) puisqu'il choisit de code vite fait un truc qui existe deja et est plus stable.
Pour ce qui concerne dbus, il me semble qu'il utilise glib mais qu'il embarque les sources directement. Comme ca, pas de problemes de dependance. Il me semble que c'est aussi ce qui avait ete envisage avec arts.
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 3.
> Pourquoi est-ce que KDE rajoute ça (ça étant au moins les signaux) par
> dessus un langage qui ne le supporte pas, autant faire du C# plutôt que de réinventer la roue ?
C'est trolltech qui rajoute ca. En effet, ca peux sembler un bon argument. Cependant, au moment ou Trolltech a choisi d'ajouter des signaux, des slots et de proprietes aux objets C++, il n'y avait aucun equivalent sur le marche, a part vaguement java, mais qui conservait des performances catastrophiques.
Ca fait une grosse difference avec Gnome qui a choisi entre plusieurs langages objets: C, C++, objective C, et qui a finalement opte pour le moins objet de tous.
> Disons que KDE a besoin d'un framework multimédia, il n'en existe pas utilisant QT nativement, donc arrêtez de faire les difficiles aussi « ah oui, on veut bien de votre framework multimédia, mais bon, on pose nos conditions »
C'est en etant tres selectif dans les technologies qu'il utilise qu'un projet etablit les bases technologiques de son succes. Ca vaut pour KDE (DCOP aui lieu de orbit), pour Gnome (orbit au lieu de mico), pour mozilla (un framework complet javascript ecrit pendant 3 ans avant de faire quoi que ce soit) et pour les autres.
On peut ne pas etre d'accord avec les choix faits, mais tu ne peux pas reprocher a un projet de choisir ses technologies soigneusement. Surtout quand il s'est deja plante une fois par le passe.
> Le pire, c'est que si le framework en question réécrivait à partir de 0 ce qui est contenu dans la glib, il y aurait moins d'opposition...
Ca ne ressort pas dans mes posts, mais personellement, je suis pour l'utilisation de la glib pour tout projet en C. Parce que si tu ne l'utilises pas, tu vas finir par la recoder tout de meme.
> > Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder
> Plus rapide et plus efficace ? En tout cas pour les trucs de base (héritage, ...) je vois pas trop en quoi ça serait plus rapide à l'exécution...
Je pensais a gobject. Pour la glib, je ne pense pas qu'il y aie de difference. D'ailleurs, quand on regarde sous les QList, on voit des grosses optimisations typiques du C (et vas-y que je te malloc tout ca et que je me deplace avec des additions sur les pointeurs).
> Cf le code de xdgmime qui a été écrit sans utiliser la glib entre autre en espérant que les gars de kde accepteraient de le réutiliser
Un naif qui s'est fait avoir. Honnetement, je pense que le consensus dans KDE est d'avoir du code propre. Apres, ca donnes des interpretations differentes sur les moyens d'arriver a ce but. Ce qui est sur, c'est qu'un mec qui recode glib a la main sera encore moins bien vu (en tout cas pour moi) puisqu'il choisit de code vite fait un truc qui existe deja et est plus stable.
Pour ce qui concerne dbus, il me semble qu'il utilise glib mais qu'il embarque les sources directement. Comme ca, pas de problemes de dependance. Il me semble que c'est aussi ce qui avait ete envisage avec arts.