Bon, on va passer sur la confusion glib/gobject, vu que les deux viennent dans la même tarball même si au final on a deux libs distinctes. La glib, c'est un ensemble de fonctions indispensables pour écrire un prog en C sans trop se prendre la tête (gestion de listes, de hash table, de chaines de caractères, ...), la couche C objet est totalement implémentée dans gobject, et la glib n'utilise pas du tout gobject.
> Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ?
le C++ gère les signaux et les "properties" ? Non ? 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 ?
> quel est l'interet pour KDE de demander en plus de ses dependances classiques, une lib en C, qui n'est parfois pas installee sur des systemes, et qui fait la meme chose que Qt ?
Ca doit être chaud à trouver un système sans glib de nos jours ;) 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 ». 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...
> 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...
> Il y a une reponse, mais comprend que si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi, indendamment des possilibites d'utiliser Qt en C (en imaginant qu'elles existent) ou des qualites intrinseques de Qt.
Si tu parles de gobject, je comprends ton point de vue, si tu parles de la glib (en excluant la partie C objet donc), faudrait arrêter de fumer la moquette :) C'est criminel aujourd'hui de forcer qqu'un à écrire un truc en C sans utiliser une implémentation de list, de hash table, ... toute faite. 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, ou bien dbus pour des exemples de mecs qui se font vraiment chier à faire du C sans glib ou assimilé pour faire plaisir à qques extrémistes kdeiens...
Sinon QT n'est comparable ni à la glib, ni aux gobjects jusqu'au jour où QT sera splitté en plusieurs libs...
[^] # Re: Re : Les nouveautés du prochain X11R6.8
Posté par Christophe Fergeau . En réponse à la dépêche Les nouveautés du prochain X11R6.8. Évalué à 1.
> Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ?
le C++ gère les signaux et les "properties" ? Non ? 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 ?
> quel est l'interet pour KDE de demander en plus de ses dependances classiques, une lib en C, qui n'est parfois pas installee sur des systemes, et qui fait la meme chose que Qt ?
Ca doit être chaud à trouver un système sans glib de nos jours ;) 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 ». 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...
> 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...
> Il y a une reponse, mais comprend que si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi, indendamment des possilibites d'utiliser Qt en C (en imaginant qu'elles existent) ou des qualites intrinseques de Qt.
Si tu parles de gobject, je comprends ton point de vue, si tu parles de la glib (en excluant la partie C objet donc), faudrait arrêter de fumer la moquette :) C'est criminel aujourd'hui de forcer qqu'un à écrire un truc en C sans utiliser une implémentation de list, de hash table, ... toute faite. 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, ou bien dbus pour des exemples de mecs qui se font vraiment chier à faire du C sans glib ou assimilé pour faire plaisir à qques extrémistes kdeiens...
Sinon QT n'est comparable ni à la glib, ni aux gobjects jusqu'au jour où QT sera splitté en plusieurs libs...