> Ce que tu sembles oublier c'est que le langage C avait été choisi
> parcque justement il était facile à "binder". . KDE n'a pas
> forcement la primeur en la manière.
Cela existe en effet depuis des annees. Mais si tu lit bien le commentaire auquel tu repons il ne parle que de "la primeur de KDE" par rapport a gnome. De plus l'interet du binding KDE est la facon dont tout est automatise et genere de telle maniere a que ce soit le plus integre dans la philosophie du langage cible (et c'est le meme script te genere le binding pour tous les langages)
> De plus créer un binding sur KDE est très (trop) limité : D'où le
> choix pour Gnome de C qui a l'avantage d'être un dénominateur
> commun à tous les langages : ils sont tous capables d'utiliser le C (ou
> presque). Je parle même pas d'un hybride C++ qui nécessite un
> précompilo si tu vois ce que je veux dire.
Je ne voit pas comment tu peux dire ca. Tu devrais jeter un oeil au bindings KDE avant de parler. Mis a part le binding c (ex: qtc) qui est un peu horrible a regarder (car tu dois comme gnome faire de l'object sans object) les autres sont complets.
Le langage C++ au lieu de poser des problemes, comme tu pense le penser, permet (par son defaut d'etre assez verbeux au niveau des headers) de belles choses.
> En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin.
> Ben en C aussi dis donc.
tres belle demonstration, tu as deja vu des headers C++ de KDE ? :)
> Même si j'ai encore des doutes sur l'intérêt, le mécanisme mis en place
> dans les libs compatible "Gnome" (à la glib quoi) permettent
> l'introspection, ce que ne permettent absoluement pas les libs KDE.
[^] # Re: Gnome, toujours trois trains de retard
Posté par Raphael Junqueira . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 3.
> parcque justement il était facile à "binder". . KDE n'a pas
> forcement la primeur en la manière.
Cela existe en effet depuis des annees. Mais si tu lit bien le commentaire auquel tu repons il ne parle que de "la primeur de KDE" par rapport a gnome. De plus l'interet du binding KDE est la facon dont tout est automatise et genere de telle maniere a que ce soit le plus integre dans la philosophie du langage cible (et c'est le meme script te genere le binding pour tous les langages)
> De plus créer un binding sur KDE est très (trop) limité : D'où le
> choix pour Gnome de C qui a l'avantage d'être un dénominateur
> commun à tous les langages : ils sont tous capables d'utiliser le C (ou
> presque). Je parle même pas d'un hybride C++ qui nécessite un
> précompilo si tu vois ce que je veux dire.
Je ne voit pas comment tu peux dire ca. Tu devrais jeter un oeil au bindings KDE avant de parler. Mis a part le binding c (ex: qtc) qui est un peu horrible a regarder (car tu dois comme gnome faire de l'object sans object) les autres sont complets.
Le langage C++ au lieu de poser des problemes, comme tu pense le penser, permet (par son defaut d'etre assez verbeux au niveau des headers) de belles choses.
> En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin.
> Ben en C aussi dis donc.
tres belle demonstration, tu as deja vu des headers C++ de KDE ? :)
> Même si j'ai encore des doutes sur l'intérêt, le mécanisme mis en place
> dans les libs compatible "Gnome" (à la glib quoi) permettent
> l'introspection, ce que ne permettent absoluement pas les libs KDE.
Mais bien sur. Et la marmotte ...