Toutes les API GNOME dans tous les langages et pour bientôt ?

Posté par  . Modéré par Nÿco.
Étiquettes :
0
19
mai
2005
Technologie
Libpoppler est une bibliothèque qui a une API GObject, le modèle objet C de la Glib utilisé dans GNOME. Un binding Python pour cette bibliothèque vient d'être réalisé.

La particularité de ce binding est qu'il a été généré automatiquement en introspectant le code C. C'est une étape importante dans le travail d'introspection de Glib, et qui devrait permettre de donner à de nombreux langages l'accès complet aux API GNOME.

NdM : Un binding permet de programmer dans un langage en se servant d'une bibliothèque écrite dans un autre langage. Les bibliothèques GNOME (GTK, gconf, libxml2, dbus, Cairo et Gstreamer pour les plus fondamentales) ont le grand avantage de couvrir à peu près tous les besoins d'une application et de le faire de façon cohérente. Elles sont aussi, comme la majorité du code dans une distribution, écrites en C, ce qui n'est pas un mal (bonne performance, code accessible à un maximum de monde). Mais le C, tout le monde n'aime pas, et c'est un langage relativement verbeux (le classement du shootout donne une première approximation).

Heureusement le C est également très portable ; en écrivant des bindings, on peut l'utiliser depuis à peu près n'importe quel langage. GTK+ en a par exemple une trentaine.

D'où un doux rêve : celui de faire pour toutes les bibliothèques qui utilisent la Glib ce qui a été fait pour GTK+. Vous programmez avec le langage que vous trouvez le plus sexy, et vous avez accès à la pile GNOME.

Entre en scène l'introspection GObject.

L'idée de l'introspection est d'extraire automatiquement l'information sur les types (enums, listes, structs...) et les objets (modèle OO genre Java) du programme, et de générer les bindings avec. Cette information est intégrée depuis longtemps dans GType, comme vous pouvez le vérifier depuis certaines démos de GTK (comme gtk+/tests/testfilechooser) qui permettent de manipuler directement les propriétés d'un objet. En vérifiant que cette information couvre bien l'intégralité d'une API, on peut générer de la glue dans un autre langage.

Le premier binding libpoppler->Python démontre la faisabilité du concept, même si il reste expérimental.

Au moment où l'on débat de savoir s'il faut élire une unique machine virtuelle pour tout écrire, l'introspection GObject propose une approche pluraliste qui bénéficie à tous et attire des développeurs de tous horizons.

Aller plus loin

  • # du déjà vu

    Posté par  (site Web personnel) . Évalué à 8.

    Autant je trouve l'approche intéressante (introspection), autant je trouve qu'il n'y a rien de nouveau sous le soleil dans les objectifs.

    Sans vouloir encore et toujours la ramener à Mono, mais ils génèrent leurs bindings pour GTK+, Gnome et autre GStreamer en utilisant depuis le début un outil qui répond aux même objectifs : créer automatiquement les bindings.

    L'utilitaire en question, c'est GAPI : http://www.mono-project.com/GAPI(...)
    L'approche est différente puisque ce sont les en-tête .h qui sont parsés et non un système d'introspection. Le résultat est le même (bien qu'on puisse récupérer un peu plus d'info dans le .h, comme le nom des arguments) et n'est plus du tout expérimental dans Mono.

    De plus l'utilitaire génère une description au format XML des API, un 2ème utilitaire permet de "patcher" au besoin (parcque ce n'est jamais parfait, ou pour modifier le design pour qu'il colle un peu plus au langage cible) et enfin un autre utilitaire qui génère le binding à partir du document XML. Vous l'aurez compris il est tout à fait possible de réutiliser ces outils pour générer des bindings dans un autre langage.
    (Ah oui au fait : avec IronPython on a déjà accès à tous les bindings Gnome automatiquement ;) )
    • [^] # Re: du déjà vu

      Posté par  . Évalué à 1.

      Tout le monde ne veut pas de mono (histoires de brevets de microsoft qui pourraient menacer mono par exemple. Attention : je n'appuie pas ces affirmations, je dis simplement que c'est un argument des opposants à mono.)
      • [^] # Re: du déjà vu

        Posté par  (site Web personnel) . Évalué à 2.

        Comme je l'ai indiqué, ce qui est généré c'est du XML, et les utilitaires utilisent Perl pour le parsing. Bref pas vraiment besoin de Mono.
        • [^] # Re: du déjà vu

          Posté par  . Évalué à 6.

          pinaraf@ubuntu:~$ gapi2-parser --help
          cannot open assembly /usr/lib/gtk-sharp-2.0/gapi-parser.exe

          Malgré mon installation foireuse, tu peux voir que pour générer les bindings via GAPI il faut mono.
          gapi2-parser - The parser is a C source and header parser that produces an XML document describing the API. (d'après le lien que t'as donné dans ton premier commentaire)
      • [^] # Re: du déjà vu

        Posté par  . Évalué à -1.

        Tout le monde ne veut pas de mono (histoires de brevets de microsoft qui pourraient menacer mono par exemple. Attention : je n'appuie pas ces affirmations, je dis simplement que c'est un argument des opposants à mono.)


        Qui etrangement , travaillent tous ou presque chez redhat , qui lui favorise gcj . De toutes facons quand on voit comment gcj se traine fasse a Mono dans les benchs , on peut se dire que Novell a fait le bon choix.
        • [^] # Re: du déjà vu

          Posté par  . Évalué à 2.

          Peux tu donner un lien vers un benchmark gcj vs mono ? Je ne trouve rien sur google qui soit récent (gcj4 vs mono 1.1, ça serait le top). Je trouve même l'inverse de ce que tu dis ! http://klomp.org/mark/free-vm-benchmarks/(...)
          Je suppose que tu voulais dire gij et pas gcj hein ? (gij c'est l'équivalent de la commande mono il me semble, alors que gcj serait plutôt un gcc puis exécution du résultat)

          Mais bon, les benchmarks restent des trucs non fiables...
          • [^] # Re: du déjà vu

            Posté par  (site Web personnel) . Évalué à 3.

            va voir dans la news qui suit, t'as bench "générique". Comme tous les bench ca vaut ce que ca vaut.

            gij c'est l'équivalent de la commande mono il me semble
            non pas du tout.
            gij c l'équivalent de mint dans le projet mono.
            • [^] # Re: du déjà vu

              Posté par  . Évalué à 3.

              http://www.shudo.net/jit/perf/(...)

              Voici un bench un peu plus sérieux que le shootup...
              • [^] # Re: du déjà vu

                Posté par  (site Web personnel) . Évalué à 4.

                Euh je vois pas en quoi ces benchs sont plus sérieux : d'abord ils ne semblent pas contredire les autres bench, et au final ce ne sont que des benchs "mathématiques", un peu comme dans les autres bench quoi.
                C'est pas parcque c'est plus "sérieux" en apparence que ca a plus de valeur : ca reste un bench et ca a les mêmes limitations que les autres : à savoir que ce ne sont généralement pas des cas concrêts et quand les résultats obtenus sont du même ordre d'idée, il est bien difficile de faire une conclusion utile.
    • [^] # Re: du déjà vu

      Posté par  . Évalué à 10.

      Pas tout à fait d'accord. L'introspection dans GObject s'apparente à la réflection dans Java. C'est une API de GObject.

      Ce qui signifie que l'on n'a pas besoin des sources de la librairie à analyser, on n'utilise que des appels GObject.

      Glade fonctionne d'ailleurs comme ça. Il fouille les objets de Gtk+ pour en extraire les propriétés et les signaux et ensuite permettre leur modification via sa GUI. C'est bien plus que simplement trouver les méthodes et les champs publics. GObject, c'est JavaBeans aux stéroïdes.

      De plus GObject permet aux bindings d'étendre les types GObject et aussi de passer des fonctions dans leur langage aux signaux. Ça va très loin. La création de bindings automatique n'est q'une utilisation de cette introspection, Glade en est une autre et qui sait, un IDE pour GObject...?
      • [^] # Re: du déjà vu

        Posté par  (site Web personnel) . Évalué à 0.

        Ben avec la méthode GAPI t'as pas besoin des libs qui fonctionnent :)
        Chacun ses dépendances mais ca change rien aux objectifs et aux résultats obtenus : avec GAPI t'obtient les méthodes, les signaux, l'arbre d'héritage, etc.
        Bref comme je l'ai dis seule l'approche est différente, mais il y en a un qui est éprouvé.
    • [^] # Re: du déjà vu

      Posté par  . Évalué à 7.

      Tout à fait, la plupart des bindings (au moins R, OCaml, Octace et donc Mono) font déjà de la génération de code: ça passe par un fichier XMl ou texte, qui contient une description des objets. Le parseur d'en-têtes GAPI est également un gros progrès, mais il est quand même nécessaire de retoucher. Force est de constater qu'il y a encore du travail manuel dans la plupart des langages, puisque la couverture des apis se limite généralement à GTK.

      L'intérêt de l'introspection est que ç'est quelque chose de complètement automatique qui se fonde sur le code compilé qui lui est 100% sûr et sans ambiguité. Le module http://cvs.gnome.org/viewcvs/gobject-introspection/(...) dans le CVS de gnome qui a été utilisé pour poppler génère un XML directement à partir des binaires, des applications comme glade et la démo gtk+/tests/testfilechooser obtiennent ces infos en linkant contre gtk.

      Ça paraissait une chose évidente à faire depuis le concept de GType qu'a la glib, mais il a fallu réviser les API pour que GObject ou GType soit utilisé partout (travail de Mathias Clasen - http://bugzilla.gnome.org/show_bug.cgi?id=139486(...) ), et écrire le compilateur binaires->xml (gobject-introspection dans le CVS).

      Une possibilité encore à explorer (et absolument pas déjà vue, dites-moi si je me trompe ;) ) est d'utiliser la version runtime de l'introspection pour générer les bindings au vol: des langages comme python supportent bien l'ajout de méthodes aux objets pendant l'exécution, ce qui permet d'utiliser libmachin sans même avoir à installer une libmachin-python.
    • [^] # Re: du déjà vu

      Posté par  (site Web personnel) . Évalué à 6.

      Le résultat est le même (bien qu'on puisse récupérer un peu plus d'info dans le .h, comme le nom des arguments)

      non, il y a plus d'informations dans les données d'introspection (metadata). C'est justement parce que le parsing des .h n'est pas toujours suffisant que cette approche est utilisée.
      On trouve ainsi : le type des éléments des listes (GSList * et GLIst *), des "flags" précisant la gestion mémoire pour les fonctions renvoyant un pointeur, des liens entre un argument de type tableau (un pointeur) et un autre argument entier contenant la longueur du tableau, etc. Il y a aussi les "properties" des gobjects et ginterfaces dans les metadata, on ne trouve pas ça dans les .h.

      Enfin ces données sont dans un fichier binaire compact et il y a une lib pour y accéder, ce qui permet aux langages dit "dynamiques" de générer les bindings à la volée (au runtime).

      Donc bref c'est pas tout à fait pareil. De plus Mono n'a non plus rien inventé, ça fait trés longtemps que plusieurs bindings utilisait des fichiers de description de l'API (les .def avec une syntaxe en sexp).
      • [^] # Re: du déjà vu

        Posté par  (site Web personnel) . Évalué à 1.

        J'ai un peu de mal à bien cerner tout de même à quoi peuvent servir ces infos : à priori tout ce que l'on cherche à générer c'est une nouvelle "vue" d'un API, quelque chose de statique et non dynamique (sinon ce n'est pas viable), et à priori je vois pas trop ce qu'on peut offrir de plus comme informations au développeur que ce qu'il y a dans les .h... ou alors même en C on a pas accès à tous les éléments... Tu pourrais préciser l'utilité dans un binding ?

        ce qui permet aux langages dit "dynamiques" de générer les bindings à la volée
        C'est un peut douteux dans la méthode tout de même :) Je vois mal comment déployer ce genre d'application qui vont découvrir à la volée un nouvel API :)

        De plus Mono n'a non plus rien inventé
        Houlà non je parle juste de ce que je connais. MS fait ca depuis très longtemps avec ses composants COM ou ActiveX.
        • [^] # Re: du déjà vu

          Posté par  (site Web personnel) . Évalué à 6.

          Tu pourrais préciser l'utilité dans un binding ?

          ben ... relis mon post, je donne 3 ou 4 exemples d'informations qui ne sont pas dans le .h.

          C'est un peu douteux dans la méthode tout de même :)

          non pas du tout, il s'agit simplement d'étendre le mécanisme de binding retardé des langages dynamique aux bibliothèques C. En python quand tu exécute un mon_objet.une_methode(un_parametre) la méthode est recherchée au dernier moment dans le dico de l'objet ; ici il s'agit de remplacer automatiquement la recherche dans le dico python par une recherche dans les données d'introspection de GTK+ suivi d'une conversion des paramètres, appel de la fonction C et conversion (dans l'autre sens) du résultat. Ça va "découvrir" l'API à la volée comme pour n'importe quel module python.

          Les bindings pyorbit du bazar CORBA fonctionnent déjà comme ça d'ailleurs.
          C'est le même principe sauf que la conversion de donnée utilisera les structures glib et les conventions d'appel de fonction C au lieu des équivalents CORBA.
          • [^] # Re: du déjà vu

            Posté par  (site Web personnel) . Évalué à 2.

            relis mon post, je donne 3 ou 4 exemples d'informations qui ne sont pas dans le .h.
            J'ai bien compris, je voulais l'utilité de ces informations dans un binding.

            Ça va "découvrir" l'API à la volée comme pour n'importe quel module python.

            Et si la méthode n'est pas là ? Non je trouve ca franchement douteux :) hors de question de déployer un truc comme ca !
            Je vois franchement pas ce que cela apporte de faire la "découverte" au dernier moment de ce genre d'info...
            • [^] # Re: du déjà vu

              Posté par  (site Web personnel) . Évalué à 2.

              J'ai bien compris, je voulais l'utilité de ces informations dans un binding.
              ben ça sert à générer du code correct pour le binding.

              Et si la méthode n'est pas là ?
              comme tous les langages dynamiques: ça se vautre comme une grosse bouse en disant « méthode truc_chose_bidule n'existe pas »
              • [^] # Re: du déjà vu

                Posté par  (site Web personnel) . Évalué à 3.

                ben ça sert à générer du code correct pour le binding.
                Visiblement Mono n'a pas besoin de ces informations, pas plus que le développeur qui n'a que les .h n'en a besoin... je veux bien croire qu'il y est un intérêt mais justement je te demande concrêtement ce qui fait que telle info est super vitale pour faire un binding et qui n'est pas présent dans un .h

                comme tous les langages dynamiques
                D'où le fait que je trouve cela "douteux". On a beau dire mais autant faire en statiques les vérifications qui peuvent l'être, et laisser s'exprimer la puissance dynamique du langage là où c'est vraiment utile (typiquement on manipule des informations dynamique). J'ai jamais compris cette obstination à vouloir faire en dynamique quelque chose qui peut l'être en statique : ca n'apporte strictement rien, à part une perte de vitesse et de robustesse. C'est pour ca que je trouve que c'est plus une "curiosité" qu'un réel intérêt d'avoir ce binding dynamique.
                • [^] # Re: du déjà vu

                  Posté par  (site Web personnel) . Évalué à 2.

                  Visiblement Mono n'a pas besoin de ces informations
                  il y a trés probablement des infos qui sont rentrées "à la main". C'est comme ça que ça marche pour les bindings utilisant les .def .

                  pour ce qui est des exemples concrets :
                  le type des éléments des listes (GSList * et GLIst *), des "flags" précisant la gestion mémoire pour les fonctions renvoyant un pointeur, des liens entre un argument de type tableau (un pointeur) et un autre argument entier contenant la longueur du tableau, etc.

                  D'où le fait que je trouve cela "douteux".
                  Tu gagne en flexibilité (pas la peine de recompiler les bindings pour chaque nouvelle version de GTK+) et tu ne perds pas beaucoup en robustesse (vu que le langage est dynamique à la base).

                  Note aussi que ça devrait permettre de diminuer la taille du code des bindings. Avec une grosse API comme GTK+, ça devient problématique.

                  En fait c'est à peu près les mêmes compromis que pour le choix entre bibliothèque statique (.a) et bibliothèque partagée (.so) en C.
                  • [^] # Re: du déjà vu

                    Posté par  (site Web personnel) . Évalué à 2.

                    il y a trés probablement des infos qui sont rentrées "à la main".
                    Il y en a certaines oui, mais généralement pour rendre certaines parties plus "friendly" au programmeur, c'est pas du tout une opération indispensable. J'ai même un peu de mal à croire qu'on génèrera automatiquement les bindings sans avoir besoin d'y toucher.

                    le type des éléments des listes (GSList * et GLIst *), des "flags" précisant la [...]
                    Euh là tu ne fais que reformuler ce que t'as déjà dis :)
                    Je te demande de me montrer un exemple concrêt de méthode ou de je ne sais quoi qui est dans un .h, qui est destiné à être bindé, et qui ne peut l'être sans ces infos accessibles uniquement par introspection. Si le programmeur C peut utiliser ces en-têtes pour compiler son programme avec ces libs sans problème, il n'y a aucune raison qu'un autre langage ne puisse pas le faire à partir de ces seuls en-tête. J'avoue que je suis très sceptique sur la réelle utilité de cette nouvelle approche.

                    Tu gagne en flexibilité (pas la peine de recompiler les bindings pour chaque nouvelle version de GTK+) et tu ne perds pas beaucoup en robustesse
                    Oué enfin c'est vraiment pas la mort de relancer un script qui regénère les bindings une fois pour toute, faut pas abuser :) Par contre ce qu'on pert en robustesse... Evidemment tu me dis que le langage ne l'ai pas à la base et que donc on peut se permettre toutes les fantaisies. Là en l'occurence c'est pour "éviter" de relancer le script de génération des bindings. Hem.
                    • [^] # Re: du déjà vu

                      Posté par  . Évalué à 2.

                      Si le programmeur C peut utiliser ces en-têtes pour compiler son programme avec ces libs sans problème, il n'y a aucune raison qu'un autre langage ne puisse pas le faire à partir de ces seuls en-tête.

                      Ta phrase est juste, tu parles bien de compiler. Par contre pour programmer, le profile d'une fonction ne suffit pas, il faut la description du comportement (par exemple de quel type sont les éléments d'une liste, exemple que tu sembles vouloir ignorer). La partie utile de ce comportement est fournie par l'introsection sous une forme normalisée ce qui n'est pas le cas d'un simple header.
                      • [^] # Re: du déjà vu

                        Posté par  (site Web personnel) . Évalué à 2.

                        Par contre pour programmer, le profile d'une fonction ne suffit pas,
                        Mais comment fait le programmeur C qui utilises ces fameuses listes ? Je te demande un exemple concrêt de méthode ou classe où les en-têtes ne suffisent pas, avec ces fameuses listes si tu veux.

                        La partie utile de ce comportement est fournie par l'introsection sous une forme normalisée ce qui n'est pas le cas d'un simple header.
                        Donc le programmeur C n'a pas le choix : il fait de l'introspection en natif avec son cerveau c'est ca ?
                        • [^] # Re: du déjà vu

                          Posté par  . Évalué à 1.

                          Donc le programmeur C n'a pas le choix : il fait de l'introspection en natif avec son cerveau c'est ca ?
                          exactement, il fait le cast qu'il faut car il sait que c'est comme ça (dû à la doc, à la logique du machin, comme son nom...). C'est hyper courant en c, en java etc... de faire ça. Sans t'offenser, si tu ne comprends pas tu dois pas programmer beaucoup en c !
                          • [^] # Re: du déjà vu

                            Posté par  (site Web personnel) . Évalué à 2.

                            Merci de t'inquiéter, mais ca fait longtemps que je programme en C. Par contre tu n'as l'air d'avoir bien saisie le sens d'introspection. Enfin j'ai la réponse à ma question plus bas sur l'utilité de la démarche et le pourquoi de l'utilisation de cette technique.
                    • [^] # Re: du déjà vu

                      Posté par  (site Web personnel) . Évalué à 6.

                      J'ai même un peu de mal à croire qu'on génèrera automatiquement les bindings sans avoir besoin d'y toucher.
                      On verra. Le coup du binding généré automatiquement c'est un peu le cas extrême, moi non plus je suis moyen convaincu. Par exemple en ocaml, on continuera à écrire des trucs à la main, c'est sûr.

                      Mais ça va quand même beaucoup accélérer la création des bindings.

                      Euh là tu ne fais que reformuler ce que t'as déjà dis :)
                      c'est toujours vrai :)

                      un exemple :
                      GList *gtk_truc_bidule_chose (machin *arg1, guint arg2);
                      est-ce que :
                      - arg1 peut être NULL ?
                      - arg1 est une simple struct passée par pointeur ?
                      - arg1 est un tableau de longueur arg2 ?
                      - arg1 est un tableau terminé par un NULL (et arg2 n'a rien à voir) ?
                      et :
                      - qu'est-ce qu'il y a dans la GList ? (des char*, des objets ?)
                      - comment gère-t-on la mémoire de la GList ? (il y a 3 possibilités: rien à libérer, libérer la GList, libérer la GList + tous les éléments).

                      Si le programmeur C peut utiliser ces en-têtes pour compiler son programme avec ces libs sans problème
                      justement, le programmeur C ne peut pas se baser uniquement sur les prototypes pour écrire du code correct, il a besoin de la doc. Le C n'est pas sûr mais tous les autres langages le sont. L'objectif est que le binding soit sûr et utilise les mêmes conventions que le langage (comme si la lib était écrite nativement dans le langage).

                      Oué enfin c'est vraiment pas la mort de relancer un script qui regénère les bindings une fois pour toute, faut pas abuser :)
                      plus besoin de compilateur C, de l'environnement de compilation de GTK+ (les .h), ni de celui du langage ...
                      • [^] # Re: du déjà vu

                        Posté par  (site Web personnel) . Évalué à 2.

                        L'objectif est que le binding soit sûr et utilise les mêmes conventions que le langage
                        Justement, là on doit se baser uniquement sur les .h. Ce que tu sembles indiquer c'est qu'il y a une sémantique supplémentaire ajoutée par les dev des libs Gnome et qui ne peut être récupéré que dynamiquement. Je comprends mieux.
                        Cela dis je me demande si il n'y a pas des "conventions" d'utilisation qui font que ce sont les même règles qui s'appliquent partout, auquel cas il est facile d'indiquer au parser d'en-tête quelles infos supplémentaires il faut déduire dans quels cas. J'aimerai un exemple concrêt autre que gtk_truc_bidule_chose, histoire de voir comment sont gérer ces cas par les parser d'en-tête justement.
                        • [^] # Re: du déjà vu

                          Posté par  (site Web personnel) . Évalué à 3.

                          Je me répond à moi même : dans le cas des tableaux il faut effectivement le préciser à la mano après coup. Si cette info peut être récupérée dynamiquement cela peut être utile puisque cela améliore nettement le binding (sans l'empêcher toutefois)
                      • [^] # Re: du déjà vu

                        Posté par  . Évalué à 1.

                        J'ai déjà travaillé sur la génération automatique d'un binding pour wxWidget en OCaml, une solution choisie par l'équipe de wxHaskell et wxEiffel (et que j'ai utilisé), c'est de proposer des entêtes plus documentés pour le typage. Par exemple, si on a besoin d'un tableau arg1 de arg2 wxFrame, et bien, on mets:

                        #define ArrayOf(Type, X, Y) Type X, int Y

                        void fun(ArrayOf(wxFrame,arg2));

                        ça permet de conserver les mêmes en-têtes pour compiler et pour parser (afin dé générer le binding)


                        Nottez que le plus difficile a sans aucun doute été la gestion mémoire. Si un tel mécanisme devait être conserver pour GTK, un effort tout particulier devrait être consacré à préciser la manière de récupérer les "objets". C'est particulièrement vrai avec les languages disposant d'un garbage collector.

                        Moralité: ça peut le faire, mais faut penser, en même temps qu'on écrit des libs, à écrire un en-tête amélioré.
  • # Tites fautes

    Posté par  . Évalué à 1.

    Dans le titre :
    "Toute_s_ les APIs"

    Dans l'article :
    (debut) "... tou_s_ les besoins d'une application..."
    (tout à la fin) "... des développeurs de tou_s_ horizon_s_."

    Mes 0.02 euros

    "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

  • # Gnome, toujours trois trains de retard

    Posté par  (site Web personnel) . Évalué à 10.

    C'est sympa comme news. Le titre est un peu trompeur, un instant, j'ai cru que Gnome avait deja des bindings pour 53 langages generes automatiquement.

    Finalement, gnome ne fait que suivre la voie de KDE:
    http://dot.kde.org/1032279318/#1032280045(...)

    A noter que la news KDE est datee de 2002. Et oui, 3 ans deja que KDE genere une partie de ses bindings de la meme facon.

    Et vous savez pourquoi c'est beaucoup plus facile avec KDE ? Le langage ! En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin. Les pointeurs ou les template ont un type precis (pas comme les void * qui sont utilises par exemple dans les listes gnome), la syntaxe est plutot simple (vous avez deja vu le nombre de declarations necessaire a faire l'equivalent d'un class Toto: public QObject en gnome ?).

    Bon, on va encore s'offusquer de ma prise de position extreme pro-KDE mais depuis que j'ai decouvert le logiciel libre, je suis persuade que Gnome a fait une grosse erreur en choisissant un toolkit en C et que KDE a fait un bon choix en choisissant du C++.

    Ceci n'est qu'un exemple de plus.
    • [^] # Re: Gnome, toujours trois trains de retard

      Posté par  . Évalué à 1.

      pour certain le C sera toujours le language roi (j'en fais parti, une majorité de developpeur gnome aussi je pense) et je suis content pouvoir programmer dans mon language préféré avec les libs gnome.


      quant aux trains de retard, je prefere être patient et avoir quelque chose qui me convient ^^
      • [^] # Re: Gnome, toujours trois trains de retard

        Posté par  (site Web personnel) . Évalué à 3.

        Y'en a aussi que ca gonfle le C, pour preuve mlview qui est actuellement porté vers C++ par son auteur.
      • [^] # Re: Gnome, toujours trois trains de retard

        Posté par  (site Web personnel) . Évalué à 9.

        Tu sais, moi aussi j'adore le C. J'aime bien faire du C pur.

        Mais quand je dois faire des objets avec de l'heritage et des methodes virtuelles, ben je choisis un langage objet. C'est etonnant hein ? De meme que si je devais faire de la programmation fonctionnelle, je me tournerai plutot vers un langage fonctionnel.

        En toute honnetete, je ne comprends pas comment tu peux a la fois aimer le C et aimer programmer en C avec Gnome. La programmation sous Gnome n'a pour moi rien a voir avec la programmation en C (que j'aime beaucoup, je le reappelle). Quand tu fais des classes, des objets, des methodes virtuelles et de l'heritage et que tu dis que tu programmes en C, tu te mens a toi-meme.

        Le C sous Gnome, c'est un mensonge. Tu fais du C++ mais en fait c'est pas du C++. T'as tous les inconvenients de ne pas avoir un langage oriente objet et aucun des avantages du C (langage sobre et efficace).
        • [^] # Re: Gnome, toujours trois trains de retard

          Posté par  (site Web personnel) . Évalué à 2.

          T'as tous les inconvenients de ne pas avoir un langage oriente objet et aucun des avantages du C (langage sobre et efficace).
          Ah si t'as l'énorme avantage de pouvoir appeler facilement un API en C depuis n'importe quel langage, alors qu'appeler un API C++ n'est pas donné à tous les langages de haut niveau. Il faut voir aussi qu'à l'époque du choix de C par Gnome le C++ n'était pas vraiment standardisé dans les compilos (je précises dans les compilos)
          • [^] # Re: Gnome, toujours trois trains de retard

            Posté par  (site Web personnel) . Évalué à 2.

            > Ah si t'as l'énorme avantage de pouvoir appeler facilement un API en C depuis n'importe quel langage

            Donc l'interet d'avoir Gnome en C, c'est de ne pas programmer en C. Super ! C'est con pour tous les mecs naifs qui ont ecrit des programmes Gnome/Gtk en C. En fait, ils se sont trompes, il fallait qu'ils utilisent plutot un binding.

            Je prefere le choix de KDE: pour programmer des bonnes applis, on prend un bon langage. Le C++ offrait et offre toujours beaucoup de possibilites et permettait d'avancer rapidement et proprement dans le developpement d'un bureau de qualite.

            Il y avait un petit inconvenient au niveau des bindings mais il faut relativiser : comme le C++ est un langage globalement de bonne qualite, le besoin de binding est beaucoup plus faible (c'est pour ca qu'il n'y a pas d'empoignades sur KDE a propos de C# ou Java. Le C++ satisfait deja une tres grande partie des developpeurs KDE et ils ne ressentent pas autant que Gnome le besoin de passer a un langage plus moderne).

            Par ailleurs, malgre cet avantage certain, les bindings de Gtk ont ete certes plus nombreux au depart, mais tres souvent pas maintenu sur le long terme, de qualite inegale, et tres peu ont inclus a la fois les bilbiotheques Gtk et Gnome. L'apparente facilite de generer des bindings en C a ete contrebalancee par la necessite de les generer a la main et donc de les maintenir. L'absence d'infos suffisante dans les .h empechait d'automatiser completement cette tache (cf les problemes cites plus haut) qui ont fait que avoir des bindings a jour sur Gnome a ete une gagure. Il faut attendre gobject pour avoir un truc propre.

            Au final, KDE a pondu un systeme de generation de binding qui s'affranchit des problemes du C++ et permet de generer des bindings pour plusieurs langages de facon automatise. Ils ont eu directement la bonne approche.

            En choisissant le bon langage des le depart, on a gagne sur les deux tableaux:
            - on programme avec KDE dans un langage moderne
            - on a une generation de binding automatisee



            > Il faut voir aussi qu'à l'époque du choix de C par Gnome le C++ n'était pas vraiment standardisé dans les compilos (je précises dans les compilos)

            Pourtant, deja a l'epoque, Qt compilait out-of-the-box sur toutes les architectures majeurs, et tous les compilos majeurs. Donc c'etait peut-etre pas la panacee, mais ca marchait tres bien. C'est sur que un truc comme boost on libsig++ qui utilise les template de facon majeure n'aurait surement pas compile a l'epoque. Ca tombe bien, Qt utilise justement tres peu les template.

            Maintenant, qu'on peut se lacher un peu plus au niveau du C++, Qt fournit aussi des trucs sympas, genre :


            QList < QString > list;
            ...
            foreach (QString str, list)
            cout << str.ascii() << endl;
            • [^] # Re: Gnome, toujours trois trains de retard

              Posté par  . Évalué à 4.

              Philippe Fremy, certains fans du C pourrait te dire que ce dernier offre autant de possibilité de developpement a condition de developper avec rigueur et de maitriser lalgorithmique en amont ^^

              L'interet de gnome est de pouvoir programmer sous environnement graphique dans le language qu'il te plait, y compris pour les vieux fan du C, qui ont le droit d'utiliser leur langage preféré ailleur que dans un shell ^^ mais aussi d'offrir un ensemble d'API de developpement pour tout les langages (car il n'y a pas que des fans du C ^^)

              je pourrais critiquer le choix du c++ par kde comme un vieil unixien integriste du C POSIX (que je ne suis pas... si bon un peu ?) mais je prefère me dire que c'est bien qu'il y en ait pour tous les gouts ^^.
        • [^] # Re: Gnome, toujours trois trains de retard

          Posté par  . Évalué à 1.

          moi aussi j'aime le c et pas la glib (c sauce gnome).

          l'avantage du c pour le binding, c'est la simplicite du "language linker", cela permet aussi d'avoir un meilleur controle a l'edition de liens.

          Le choix du cpp n'empeche pas Qt et KDE de faire des bindings tres rapidement, donc cela ne justifie pas le choix de gnome. L'autre paradoxe qui me fait aimer KDE par rapport a gnome, c'est la 'quasi' compatibilite binaire entre les versions 3.1, 3.2, 3.3, 3.4, malgres les options de compilation qu'utilisent les distros et le partage des composantes entre les appli.
        • [^] # Re: Gnome, toujours trois trains de retard

          Posté par  . Évalué à 1.

          pour moi la prog Gnome reste quand meme plus sobre que du C++, mais je ne cherche pas à lancer pas une baston C++ vs C, je signalai juste mes gouts en matière de prog (par rapport au critique du choix du C par gnome).

          Je précise quand même que dans mon cas, je vois le C comme de l'assembleur de haut niveau portable ^^ simple à debugger et à optimiser (et limite simple a compiler de tête)
    • [^] # Re: Gnome, toujours trois trains de retard

      Posté par  (site Web personnel) . Évalué à 0.

      Ce que tu sembles oublier c'est que le langage C avait été choisi parcque justement il était facile à "binder". De plus si t'avais pris la peine de te renseigné, il existe depuis le départ des outils permettant de créer des bindings automatiquement à partir des .h. KDE n'a pas forcement la primeur en la manière.
      De plus créer un binding sur KDE est très (trop) limité : le langage C++ utilisé n'est pas forcement facile à utiliser dans tous les langages de haut niveau, et très peu de langage de haut niveau implémente toutes les fonctionnalités de C++ : il en ressort des difficultés à créer le binding, voir parfois une impossibilité dans certains langage. 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.

      En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin.
      Ben en C aussi dis donc.
      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.

      Voilà pour ce qui était de la réplique pro-Gnome ;)
      • [^] # Re: Gnome, toujours trois trains de retard

        Posté par  . Évalué à 5.

        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.
        Là tu te plantes !
        En effet, le (décrié) moc de Qt c'est Meta Object Compiler. Et il permet de connaître les signaux, slots, propriétés.. d'un objet très facilement. Par exemple Qt-Designer fonctionne ainsi.
        Cf http://doc.trolltech.com/3.3/qmetaobject.html(...)
        • [^] # Re: Gnome, toujours trois trains de retard

          Posté par  (site Web personnel) . Évalué à 1.

          Houlà oui autant pour moi :) Désolé pour la connerie monstrueuse. J'avais oublié que le (décrié) meta-compilo-qui-fait-chier était puissant :)

          Enfin ca confirme ce que je pensais : bien que proposant également l'introspection, visiblement les "bindeurs" KDE n'en ont pas eu besoin pour faire de la génération automatique, les .h leurs suffisent. Je vois pas pourquoi il ne serait pas de même pour Gnome et ses .h.
          • [^] # Re: Gnome, toujours trois trains de retard

            Posté par  . Évalué à 3.

            > visiblement les "bindeurs" KDE n'en ont pas eu besoin pour faire de la
            > génération automatique, les .h leurs suffisent.

            Ca n'est pas totalement vrai.
            Cela est vrai pour les bindings des langages "statiques" (ex: C) par contre pour les langages "dynamiques" (du genre python, ruby, etc...) le binding exploite a fond les capacites de moc

            > Je vois pas pourquoi il ne serait pas de même pour Gnome et ses .h.

            Il est plus facile de partir de bcp d'informations (ie. typage assew fort dans les headers c++) et de "degrader" que le contraire (probleme du fameux "void*" du c)
          • [^] # Re: Gnome, toujours trois trains de retard

            Posté par  (site Web personnel) . Évalué à 2.

            > Je vois pas pourquoi il ne serait pas de même pour Gnome et ses .h.

            Parce que comme l'objet ne fait pas partie de la syntaxe C, il est emule a coup de macros et de struct, qui sont beaucoup plus difficile a parser.

            Qui plus est, un certain nombre d'information sont tout simplement perdue dans la syntaxe C. Je pense aux signaux Gtk qui acceptent un argument de type void *

            cf
            http://www.gtk.org/tutorial/sec-theoryofsignalsandcallbacks.html(...)

            Tu noteras la presence de gpointer callback_data qui est impossible a interpreter pour un outil de binding automatique.

            Au contraire, les signaux et slots Qt sont types et peuvent donc etre pris en compte dans une generation automatique.

            De meme, les listes Gtk ne sont pas typees. Elles prennent aussi un gpointer pour la partie data donc tu ne sais pas de quoi est faite la liste. En C++, les listes sont faites avec des templates ou le type est explicitement visible.
      • [^] # Re: Gnome, toujours trois trains de retard

        Posté par  . Évalué à 3.

        > 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.

        Mais bien sur. Et la marmotte ...
        • [^] # Re: Gnome, toujours trois trains de retard

          Posté par  (site Web personnel) . Évalué à 2.

          Le langage C++ au lieu de poser des problemes, comme tu pense le penser
          Il pose pas des problèmes pour récupérer les infos, le langage C++ étant par nature objet il est sans doute plus facile de récupérer certaines infos, mais je parle de la réalisation du binding en soit : en gros faut faire un wrapper C++ intermédiaire qui soit plus friendly car très peu de langage comprennent "nativement" le C++, contrairement au C avec lequel la plupart des langages sont capable d'intéragir. Je ne suis pas sûr qu'une couche intermédiaire soit un gage d'efficacité, et il faut refaire cette couche pour tous les langages... C'est en ce sens que le binding d'API C++ est "lourd" à mon sens.

          tres belle demonstration, tu as deja vu des headers C++ de KDE ? :)
          Ce que je voulais dire c'est que pour faire le binding "tel quel", les .h suffisent, aussi bien en c++ qu'en C. Après je viens enfin de comprendre l'intérêt de l'introspection dans certaines situation, notamment pour améliorer considérablement la sémantique du binding et rendre le tout plus friendly au langage de haut niveau. J'aurai tout de même aimé retrouver cette info dans la news, car c'est vraiment là que réside l'intérêt de l'approche à mon sens.

          Mais bien sur. Et la marmotte ...
          Oué je me suis planté je sais.
          • [^] # Re: Gnome, toujours trois trains de retard

            Posté par  (site Web personnel) . Évalué à 3.

            > en gros faut faire un wrapper C++ intermédiaire qui soit plus friendly

            De fait, il y a une couche intermediaire en C qui est generee (il me semble).

            > Je ne suis pas sûr qu'une couche intermédiaire soit un gage d'efficacité,

            Comment tu peux parler d'efficacite d'une couche intermediaire alors que utilise un langage ou tout le framework objet est genere par macro et ne peux donc pas etre optimise par le compilateur. En C++, tu donnes beaucoup d'info sur tes structures au compilateur, qui peut donc les optimiser en consequence. Avec un wrapper objet en C comme on a en Gtk/Gobject, le compilateur ne peut pas faire ce type d'optimisation parce qu'il ne sait pas ce que c'est qu'un objet.

            > il faut refaire cette couche pour tous les langages

            Ben non, c'est la meme partout. C'est elle justement qui fournit le coeur de binding. Elle fournit tous les services dont le binding va avoir besoin (introspection, typage dynamique pour certains langages, ...) en C.

            > les .h suffisent, aussi bien en c++ qu'en C.

            Justement, non. Une partie des informations sur un objet en Gtk est contenu dans les structures qui sont definies dans le .c, pas dans le .h
            • [^] # Re: Gnome, toujours trois trains de retard

              Posté par  (site Web personnel) . Évalué à 1.

              Yahoo. Donc tu proposes de mettre une couche C à KDE. Clap clap clap. Tu dis que en c++ c ouachement mieux parcque c optimisé par rapport à C machin machin, et tu proposes de justement de rajouter une couche qui, si on te suit, n'est pas optimisé puisqu'en C. Cherche l'erreur.

              Justement, non.
              Ah si. Si tu veux te contenter d'appeler les API à la mode C, t'as toutes les infos nécessaire dans le .h. J'ai moi même tenter quelques bindings à la mano directement et y'a tout ce qu'il faut. Après c'est une question de style et d'intégration, on a envie qu'un tableau s'appelle un tableau (et non un pointeur + une taille), on peut avoir envie de typer leur contenu, etc, mais ce n'est pas indispensable au fonctionnement d'un binding (même si indispensable à faire un bon binding).
              • [^] # Re: Gnome, toujours trois trains de retard

                Posté par  (site Web personnel) . Évalué à 5.

                << Yahoo. Donc tu proposes de mettre une couche C à KDE. Clap clap clap. Tu dis que en c++ c ouachement mieux parcque c optimisé par rapport à C machin machin, et tu proposes de justement de rajouter une couche qui, si on te suit, n'est pas optimisé puisqu'en C. Cherche l'erreur.
                >>

                Tu peux essayer de tourner la phrase pour que ce que je dise paraisse debile mais je maintiens.

                Tu as plusieurs niveaux:
                - Gtk (avant gobject), avec un framework objet emule en C, et eventuellement un binding genere a la main. Le compilateur ne peut pas optimiser correctement les parties objet du code car il ne connait pas l'objet. Les bindings attaquent directement les .h de gtk (bien que ce point soit a verifier, je ne serait pas surpris qu'il y aie des couches intermediaires, par exemple pour gerer le comptage de reference et autres joyeusetes des langages de script).

                - KDE, avec un framework en C++, que le compilateur peut optimiser correctement. Ce framework genere ensuite une _interface_ en C, qui utilise en interne du C++ (qui est donc optimisee correctement par le compilateur), mais qui ajoute au moins un appel de fonction par methode. Pour info, le cout d'un appel de fonction de nos jours et negligeable, plus particulierement dans un gui ou c'est l'utilisateur qui declenche les evenements.

                - Gnome + Gobject : le framework objet s'est complexifie, mais est toujours en C (donc toujours aussi difficile a optimiser) mais en plus, on genere une couche intermediaire qui sert a interfacer le binding. Bref, on cumule deux inconvenients en terme de performance, mais on gagne en qualite des bindings et en quantite de travail.

                Il serait interessant de valider ce que j'affirme avec des benchs. Je serai infiniment surpris si l'appel d'une methode virtuelle en gobject etait plus rapide qu'en C++. J'essaye d'imaginer le nombre d'etape intermediaire par lequel le code C passe pour simuler une methode virtuelle.

                > Si tu veux te contenter d'appeler les API à la mode C, t'as toutes les infos nécessaire dans le .h

                Ok, je prends deux fonctions au hasard:
                cf http://developer.gnome.org/doc/API/2.0/glib/glib-String-Utility-Fun(...)

                - g_strstr() renvoie un gchar * deja alloue a ne pas liberer.
                - g_strdup_printf() renvoie un char * qui doit etre libere.

                Dis moi comment un binding base sur une moulinette du .h peut savoir si il doit faire des gfree sur les chaines renvoyees par ces fonctions. Tu es oblige d'inclure une phase manuelle basee sur la documentation que tu auras lu.
                • [^] # Re: Gnome, toujours trois trains de retard

                  Posté par  (site Web personnel) . Évalué à 1.

                  Avec ta couche supérieur en C par dessus le C++ le compilateur aura les même problèmes quand le langage de haut niveau cherchera à dériver le code C++ : il sera bien enmerder pour optimiser.
                  mais bon franchement on s'en balance des différences de perfs entre C++ et C objet, même si elles existent, le principal problème viendra de toute façon du binding dans le langage de haut niveau, ce binding constituera la plus lente des couches intermédiaires, avec tous les problèmes de perf lié au marshaling.

                  Tout ce que je constate c'est qu'au final le C est nécessaire, et KDE devrait proposer des API sous cette forme, même s'ils veulent par derrière utiliser un API C++. Mais fournir aux utilisateurs une API C++ (non standard), c'est vraiement pas faciliter la vie des binders.

                  Dis moi comment un binding base sur une moulinette du .h peut savoir si il doit faire des gfree sur les chaines renvoyees par ces fonctions.
                  Le binding s'en fou, il expose les api tel quel, au programmeur d'appeler le gfree dans son langage de haut niveau si besoin est. Bref, pour faire un binding de base "idiot" les .h suffisent et c'est tout à fait automatique et fonctionnel. Par contre si on veut cacher certains aspects techniques (gestion mémoire) pour simplifier la vie du programmeur ou faciliter l'intégration dans un langage de haut niveau, là oui il faut plus d'info. Mais ca c'est ce que j'ai déjà dis.
                  • [^] # Re: Gnome, toujours trois trains de retard

                    Posté par  (site Web personnel) . Évalué à 2.

                    Le binding s'en fou, il expose les api tel quel, au programmeur d'appeler le gfree dans son langage de haut niveau si besoin est. Bref, pour faire un binding de base "idiot" les .h suffisent et c'est tout à fait automatique et fonctionnel.

                    N'importe quoi. Personne ne fait ça. Ça n'a pratiquement aucun d'intérêt un tel binding qui te fait perdre les garanties de sûreté du langage. C'est déjà quasi-impossible de faire en sorte que le programmeur C gère correctement sa mémoire, alors un programmeur habitué à un autre langage ...
                    • [^] # Re: Gnome, toujours trois trains de retard

                      Posté par  (site Web personnel) . Évalué à -1.

                      T'as lu ma phrase ? J'ai dis que c'était idiot.
                      • [^] # Re: Gnome, toujours trois trains de retard

                        Posté par  (site Web personnel) . Évalué à 4.

                        Et ca te gene d'argumenter comme ca ?

                        On parle de faire un binding, et toi tu nous dis que pour faire un truc completement merdique, c'est facile. C'est super interessant comme info.
                        • [^] # Re: Gnome, toujours trois trains de retard

                          Posté par  (site Web personnel) . Évalué à 2.

                          Depuis le début je disais qu'il était tout à fait possible de faire un binding à partir des .h automatiquement. Ma question était donc : que va apporter l'introspection. J'ai eu des réponses qui m'on convaincu et j'ai compris l'apport d'une telle méthode. Cependant certains s'évertuaient encore à dire qu'il n'était pas possible de se contenter du parsing de .h. Basiquement si. Je l'ai fait pour binder gstreamer, et même si ce n'était pas super bien intégré dans le langage cible c'était tout à fait exploitable.
                          • [^] # Re: Gnome, toujours trois trains de retard

                            Posté par  (site Web personnel) . Évalué à 2.

                            Ok, je comprends mieux. Pour un besoin ponctuel et limite, c'est en effet exploitable. Mais dans le cadre ou tu proposes un framework de developpement comme Gnome, ce n'est pas le cas.

                            Le but du binding, c'est de proposer le confort du langage cible, avec les fonctionnalites du projet original. Ca demande beaucoup de travail affinage pour que toutes les problematiques de binding, de gestion de memoire et autres restent transparentes.
                  • [^] # Re: Gnome, toujours trois trains de retard

                    Posté par  (site Web personnel) . Évalué à 3.

                    > Avec ta couche supérieur en C par dessus le C++ le compilateur aura les même problèmes
                    > quand le langage de haut niveau cherchera à dériver le code C++ : il sera bien enmerder pour optimiser.

                    Ben non. La derivation a deja ete faite en C++ (donc deja optimisee). Ensuite, la classe est visible dans ton langage cible. Si ce langage supporte la derivation, la derivation sera faite dans ce langage cible. La couche c ne sert vraiment qu'a transferer des appels.

                    Cela dit, tu as probablement raison que le plus lent, dans tout ca, c'est le langage cible. Sauf si ce n'est pas un langage de script : ada, ocaml, objective C.

                    > le C est nécessaire, et KDE devrait proposer des API sous cette forme,

                    Ben non, on est pas maso. Si tu veux faire des applis C graphiques, va voir Gnome, tu seras plus heureux. Les devs de KDE ont des criteres de qualite pour la facilite de developpement que le C ne remplit pas, et encore moins du C wrappant du C++. Ca a ete fait a une epoque et c'etait immonde.

                    Je pense qu'il est possible de voir l'avantage de programmer dans un langage objet lorsque tu manipules des concepts objets a tour de bras. Quitte a faire un binding aussi debile, je preferai le faire pour le brainfuck (http://www.muppetlabs.com/~breadbox/bf/).(...) Au moins, je sais pourquoi je le fais.

                    > Mais fournir aux utilisateurs une API C++ (non standard), c'est vraiement pas faciliter la vie des binders.

                    Pourquoi est-ce que j'ai l'impression de me repeter 23 fois ? Ton argument est completement ecule. D'une part, il semble avoir ete exprime ici clairement que le C est loin de faciliter la vie des binder non plus pour d'autres raisons. D'autres part, KDE a resolue ce probleme du C++ en generant automatiquement une couche intermediaire en C extraite automatiquement des headers KDE.

                    Donc KDE facilite la vie des binders sur deux plans, et ce depuis 2002:
                    - la generation des api KDE dans un langage intermediaire est automatisee et maintenue a chaque version de KDE : pas besoin aux binders de maintenir cette partie la
                    - ils doivent uniquement s'occuper de la semantique du langage qu'ils binde, sachant que smoke prevoit deja toutes les caracteristiques des langages de scripts actuels : introspection et typage dynamique notamment.
                    • [^] # Re: Gnome, toujours trois trains de retard

                      Posté par  (site Web personnel) . Évalué à 2.

                      Sauf si ce n'est pas un langage de script : ada, ocaml, objective C.
                      Vois pas le rapport : tu auras toujours le problème du marshaling, en mode compilé aussi.

                      Oué bon laisse tomber. Je te dis qu'il faudrait proposer une couche externe en C pour faciliter la vie des binders, toi tu me réponds : "on est pas maso" ou "c'est immonde", et 10 lignes plus bas tu me dis "KDE a resolue ce probleme du C++ en generant automatiquement une couche intermediaire en C extraite automatiquement des headers KDE." avant d'avoir bien sûr précisé " le C est loin de faciliter la vie des binder non plus pour d'autres raisons." Pourtant si KDE génère ca automatiquement c bien justement pour faciliter la vie des binders qui préfèrent appeler du code C !
                      Enfin heuresement j'ai eu les réponses à toutes mes questions à travers ces différentes contradictions ;)

                      Reste qu'il y a toujours un problème à régler : il faut toujours maintenir pleins de bindings, pour chaque langage cible.
                      • [^] # Re: Gnome, toujours trois trains de retard

                        Posté par  (site Web personnel) . Évalué à 2.

                        J'avais mal interprete ta phrase. J'ai cru que tu demandais une couche en C pour programmer sous KDE, et c'est a cette possibilite que je faisais reference.

                        Sinon, de fait, KDE propose une couche en C automatiquement generee, qui ne demande pas de maintenance. Le developpeur du binding n'a plus qu'a integrer cette couche dans un moteur et hop, ca marche (ca doit etre un poil plus complique quand meme) donc il n'a lui aussi pas de maintenance (theoriquement) a effectuer.
                        • [^] # Re: Gnome, toujours trois trains de retard

                          Posté par  (site Web personnel) . Évalué à 2.

                          MMh ca n'empêche que cette couche C doit avoir tous les inconvénients de Gnome pour être exploitable, cad offrir des possibilités d'introspection par exemple pour faciliter le binding...
                          Enfin dans tous les cas il y a toujours le problème de maintenir les bindings dans tous les langages, quelque soit la méthode il n'y en a aucune de parfaite (enfin jusqu'à présent).
    • [^] # Re: Gnome, toujours trois trains de retard

      Posté par  . Évalué à 9.

      > En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin

      Evidement puisqu'en C++ tu as 99% du code dans les .h....
  • # Déjà vu, episode 2

    Posté par  (site Web personnel) . Évalué à 7.

    Ça s'appelle XPCOM, et c'est utilisé dans le framework Mozilla depuis des années (aller, on va dire au moins 5 ans).

    On peut programmer ses objets/composants dans le langage que l'on veut, du moment qu'il y a le binding adéquate dans XPconnect (la couche applicative qui permet l'interconnection entre tous les composants XPCOM). Chaque composant peuvent implementer une ou plusieurs interfaces (déclarées en IDL)

    Actuellement, on peut développer des composants XPCOM, en C++, Javascript, Python, Ruby, perl.
    • [^] # Re: Déjà vu, episode 2

      Posté par  (site Web personnel) . Évalué à 5.

      oui d'ailleurs :
      The format of GObject metadata is strongly influenced by the Mozilla XPCOM format.

      (ça vient du README de la fameuse lib d'introspection)
  • # Employer Volubile au lieu de verbeux, c'est plus Français et plus exact

    Posté par  (site Web personnel) . Évalué à 0.

    Merci pour la nouvelle sinon.
    • [^] # Re: Employer Volubile au lieu de verbeux, c'est plus Français et plus ex

      Posté par  . Évalué à 3.

      Volubile : se dit de quelqu'un qui parle beaucoup.

      Verbeux : indique l'utilisation de trop de mots pour s'exprimer.

      On peut trouver une nuance de plaisir dans la volubilité. La verbosité par contre est une plaie pour l'auditeur ou le lecteur, du moins quand il ne manque pas de goût. Comme exemple, la séquence initiale de Pulp Fiction montre des personnages volubiles. Beaucoup de films italiens jouent sur le fait de montrer un peuple volubile. Des exemples de verbosité ? Les oeuvres de Bernard-Henri Lévy (toutes catégories confondues), les interventions télévisées ou radiophoniques de Francis Lalanne. D'une manière imagée on peut dire que quelque chose est verbeux lorsque les mots cachent les idées ou leur absence.

      Donc je trouve au contraire que le choix de verbeux comme adjectif est pertinent.
    • [^] # Re: Employer Volubile au lieu de verbeux, c'est plus Français et plus ex

      Posté par  . Évalué à 4.

      Et « cesser de faire souffrir des mouches innocentes », ce serait pas l'expression adaptée ?
  • # Contre les bindings automatiques

    Posté par  (site Web personnel) . Évalué à 3.

    Même si ça a l'avantage de permettre d'utiliser rapidement la bibliothèque dans son langage favori sans travail, je n'aime pas les bindings générés automatiquement.
    En effet, ils integrent la lib dans le langage avec son esprit, alors que je prefère que l'API soit adaptée au langage.

    Des choses comme par exemple ce que renvoit une methode set_* (l'objet ? le parametre ? rien ?), ou meme les convention de nom des methodes, dépendent du langage.

    Il est possible bien sur de partiellement automatiser ces conversions mais je ne l'ai vu jusqu'à présent dans aucun système de génération de bindings.
    Il est parfaitement imaginable d'automatiquement creer dans le binding ruby la methode foo= quand la methode s'appelle set_foo et prend un seul parametre ou foo? pour is_foo. Par contre, certains choix qui me plaisent dans le binding ruby-gnome2 n'auraient je pense pas été mis dans un generateur. Par exemple avec la libglade, my_glade_object.get_widget('foo') qui peut s'ecrire my_glade_object['foo'].

    De plus il semble inutile d'avoir certaines methodes, par exemples celles liées à la gestion mémoire dans un langage ou c'est fait de manière transparente habituellement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.