Journal Un langage pas comme les autres : Vala

Posté par .
1
23
mar.
2007
Salut à tous,

Une recherche sur linuxfr pour le terme "vala" met bien en valeur la pauvreté de l'orthographe des linuxèfèriens. En effet c'est à chaque fois une orthographe douteuse du mot "voilà" qui est recensé.

Pourtant, à propose de langue, Vala est un vrai langage ! Un vrai langage, mais un langage pas comme les autres. Son but est simple et paraît pas franchement novateur au premier coup d'½il :

Vala veut donner au développeur Gnome les fonctionnalités de langages modernes sans ajouter de nouvelle dépendance à l'exécution, ni utilise une ABI différente de celle des logiciels et bibliothèque écrite en C.

Concrètement, Vala traduit un synthaxe proche du C# directement en C/GObject. La syntaxe est adaptés au spécificité du système de typage de GObject (signaux, greffons, etc.). Ou comment inventer un langage sans en créer un autre ;).

Comment utiliser une bibliothèque en C dans du Vala ? Pas besoin de passerelle à l'exécution, il suffit de fournit un définition d'API à vala pour qu'il fasse la traduction, au final, c'est toujours du C. Il existe déjà un outils vapigen qui génère automatiquement un définition d'API à partir de bibliothèque GObject. Cet outils est basé sur un outils similaire du projet Mono.


Je trouve ce langage franchement révolutionnaire pour Gnome ! C'est un fait reconnu que le C/GObject est fastidieux, mais rien de garantie mieux performance et ouverture vers les autres langages. Il n'y a même pas besoin de définir Vala comme un langage accepté dans Gnome, puisque c'est du C !

Le projet est encore à un état instable, mais on peut déjà écrire un "Salutations"¹ en Gtk+ ! La version 0.0.7 contient pas mal de test (29) qui permette de voir l'évolution du support du langage.

Courrez vite visiter http://live.gnome.org/Vala !

Étienne.

¹. J'utilise "Salutations" pour traduire "Hello world!", c'est mon choix©®™.
  • # La différence

    Posté par . Évalué à 2.

    Un bon moyen de voir l'utilité de vala, c'est de prendre un .vala fournit sur le wiki et de le traduire en C avec valac --pkg gtk+-2.0 *.c. La différence en nombre d'octets tes pharamineuses ! Et le code C est propre !

    Étienne.
    • [^] # Re: La différence

      Posté par . Évalué à 2.

      Genre comme le deuxième exemple où un signal foo est défini, et où une lambda expression foo est définie ?
  • # Vala

    Posté par . Évalué à 10.

    Goto ?
    • [^] # Re: Vala

      Posté par . Évalué à 10.

      Non, ce serait valà.

      La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

  • # ...

    Posté par . Évalué à 2.

    Many developers want to write GNOME applications and libraries in high-level programming languages but can't or don't want to use C# or Java for various reasons, so they are stuck with C without syntax support for the GObject type system.
    Et le python, ruby , (C++) ils sont ou ?
    • [^] # Re: ...

      Posté par . Évalué à 1.

      Essaie de faire une bibliothèque aussi performante dans ces langages, essaie de faire une passerelle ruby->python, :).

      La règle pour être intégré dans la plateform de Gnome, c'est d'être en C/GObject. Après, il y a les passerelles.

      Étienne.
      • [^] # Re: ...

        Posté par . Évalué à 2.

        Essaie de faire une bibliothèque aussi performante dans ces langages,
        Je croyais que le pb, ct que les bibliothèque était en C mais que les applis voulais des language de haut niveau.

        Et puis C et performance, ca veut rien dire : si on ajoute une couche haut niveau (exception, garbage collector, ...) et ben ca a un cout.

        essaie de faire une passerelle ruby->python, :).
        Pourquoi faire du ruby->python ?
        GTK c'est du C et je proposais des applis en python/ruby.

        J'ai jamais essayé de faire de telle passerelle, mais j'ai déja vu plusieurs passerelle python/ruby -> C.



        PS : j'ose meme pas imaginer débugger des programmes ecrit en vala (en tout cas avec le backend C de gdb)...

        PS2 : qd on voit le succes objective C (en openstep), j'espere qu'il aura plus de succes.
        • [^] # Re: ...

          Posté par . Évalué à 2.

          > Et puis C et performance, ca veut rien dire : si on ajoute une couche haut niveau (exception, garbage collector, ...) et ben ca a un cout.

          Au moins, la surcouche est à la compilation, pas à l'exécution. Et le système de typage GObject est largement plus performant que ce qu'on trouve en Java, Python, C# etc. Rien que par le fait de mixer les types natifs (avec gint, gchar, gpointer, gboolean) et les types "haut niveau" (G_TYPE_OBJECT, G_TYPE_INTERFACE et leurs enfants).

          Cordialement,
          Étienne.
          • [^] # Re: ...

            Posté par . Évalué à 5.

            Au moins, la surcouche est à la compilation, pas à l'exécution.
            A bon, parce que les fonctions de la glib on les appele pas ou parce qu'elle ne font rien ?

            Et le système de typage GObject est largement plus performant que ce qu'on trouve en Java, Python, C# etc.
            Un bench serait le bienvenu.

            Un langage de plus haut niveau peut etre plus performant que du C sur des trucs de haut niveau parce que le developeur se concentre sur ce qu'il veut faire, le language (et le framework) se charge de choisir ce qui se fait de mieux (algo optimisé choisi dynamiquement en fonction de l'entrée) et eviter au developpeur d'avoir a reinventer la roue pour interfacer les différents composants (qui d'ailleurs si c'est mal fait peu etre catastrophique au niveau perf ou au niveau evolutivité).

            Dire que le C est plus rapide que les langages haut niveau, c'est aussi stupide que dire que l'assembleur est plus rapide que le C :
            C'est vrai si t'as des developpeurs qui sont des génies, qui connaisent toute les optimisations possibles, qui on du temps devant eux.

            C'est rarement le cas dans la realité.

            (Je ne crache pas sur le C, mais chaque langage a ses propriétés et ses applications).

            PS: je comprend parfaitement que la majeur partie de gnome est écrite en C, et qu'ils doivent faire avec. vala peut etre une solution, mais je la considere plus comme une rustine, qu'un truc revolutionnaire.
            • [^] # Re: ...

              Posté par . Évalué à 3.

              Un langage de plus haut niveau peut etre plus performant que du C sur des trucs de haut niveau parce que le developeur se concentre sur ce qu'il veut faire(...)

              ah non, là tu confonds les capacités du développeur et celles du langage...
              • [^] # Re: ...

                Posté par . Évalué à 7.

                Héhé, avec un raisonnement pareil, il n'y a que les idiots qui ne coderaient pas en assembleur parce qu'il sont trop stupide pour ça, et pas parce que c'est une perte de temps de lire et d'écrire des "jump label" au lieux de faire du polymorphisme. Tu sais le "je réfléchis plus à mon algorithme et à mon modèle qu'à mon code" ...

                Sérieusement, tu auras beau être super doué, c'est plutôt agréable de se reposer sur un langage haut niveau pour implémenter un algo proche de ce qu'on a imaginer que de pisser de la ligne au kilomètre pour faire la même chose ... et plus rapide. Ce qui laisse du temps pour faire autre chose.

                Le tout à compétence du développeur égale. Alors, l'expressivité (l'efficacité on va dire) du langage n'a vraiment aucune importance ?
                • [^] # Re: ...

                  Posté par . Évalué à 2.

                  > tu confonds les capacités du développeur et celles du langage

                  avec un raisonnement pareil, (...)


                  de quel raisonnement tu parles ?


                  Alors, l'expressivité (l'efficacité on va dire) du langage n'a vraiment aucune importance ?

                  j'ai dit ça ? non-non. et puis tu négliges des tas de paramètres comme la disponibilité et la maturité de ces fameux "langages haut niveau" et de tout ce qui va avec, bibliothèques, outils complémentaires, méthodes, sans même parler d'éventuels problèmes de licence.
            • [^] # Re: ...

              Posté par . Évalué à 8.

              Un langage de plus haut niveau peut etre plus performant que du C sur des trucs de haut niveau parce que le developeur se concentre sur ce qu'il veut faire, le language (et le framework) se charge de choisir ce qui se fait de mieux


              Hum, non, un langage de haut niveau peut être plus performant que du C parce que le compilateur dispose d'informations de plus haut niveau qui peuvent lui permettre de faire de meilleurs choix qu'un compilateur C qui a une vision plus limitée du programme.

              Par exemple en utilisant GObject pour faire de l'objet en C, on a des pointeurs de fonction dans tous les sens. Le C++ peut être plus efficace rien qu'en décidant d'inliner certaines fonctions quand c'est possible (recopier le code au lieu de faire des appels de fonction).

              Le problème peut toujours théoriquement être contourné par le programmeur qui peut faire des choix "de haut niveau" à la place du compilateur, mais il est inenvisageable que ce soit le programmeur qui transcrive un concept de haut niveau comme l'héritage entre ses classes en code de bas niveau. Sur un petit programme c'est faisable, mais totalement impossible à maintenir après. D'où le fait que, même quand on code en C, on fait des compromis entre rapidité d'exécution et temps de développement, et on se retrouve avec du code générique plus lent que l'optimum.
            • [^] # Re: ...

              Posté par (page perso) . Évalué à 3.

              L'avantage du C est aussi d'être compatible avec beaucoup d'autres langages. Avec le C++ ce n'est plus forcément si évident.
    • [^] # Re: ...

      Posté par (page perso) . Évalué à -6.

      DANS TON CUL !
  • # Performances

    Posté par (page perso) . Évalué à 10.

    >>> C'est un fait reconnu que le C/GObject est fastidieux, mais rien de garantie mieux performance et ouverture vers les autres langages

    Si le C est la garantie de bonnes performances alors pourquoi Nautilus est-il si misérablement lent ? Pourquoi Gnome est, d'une manière générale, assez lourd à l'utilisation ?

    PS : c'est un gnomiste convaincu qui pose la question.
    • [^] # Re: Performances

      Posté par . Évalué à 1.

      Salut,

      Bonne question. C ne veut pas dire optimisé. Mais nautilus en ruby, j'ose pas imaginer ;).

      > pourquoi Nautilus est-il si misérablement lent

      Gnome-VFS est super lent et foireux. Sinon, en local je trouve pas nautilus si lent.

      > Pourquoi Gnome est, d'une manière générale ?

      Un bout de réponse : les perfs de cairo (cf dépêche 1.4), le bugs d'optimisation, etc.

      Ni Gnome, ni C ne sont parfait ! Mais j'ose pas imaginé Gnome si Gtk était écrit en ruby, cairo en C# et nautilus en C++ …

      Étienne.
      • [^] # Re: Performances

        Posté par . Évalué à 2.

        Peut être que gnome-vfs serait moins foireux, que les devs auraient eu plus de facilité à optimiser Cairo et que le bug d'optimisation ne serait pas apparu ?

        Parce que les dev auraient eu moins besoin de se concentrer sur l'utilisation de trucs bas niveaux pour faire en réalité plutôt des trucs (en général) hauts niveaux ...
        • [^] # Re: Performances

          Posté par . Évalué à 1.

          gnome-vfs est pas franchement une techno apprécié de gnome. Cf. vio sur freedesktop. http://lists.freedesktop.org/archives/xdg/2007-January/00914(...)
          • [^] # Re: Performances

            Posté par . Évalué à 2.

            Héhé, encore une preuve que le C c'est la panacée pour implémenter une techno ^^

            Le prends pas mal, mais j'ai un peu l'impression que tu réponds à côté, là, le propos c'était :

            >>gnome vfs est lent, d'autres trucs sont foireux
            > c'est peut être à cause du C
            gnome-vfs est pas très apprécié ...


            Ben justement, peut être que si gnome avait été pensé plus haut niveau et pas pour être implémenté en C, peut être qu'il serait plus apprécié.

            (bon ok, j'ai pas beaucoup d'argument, mais toi t'en es aussi au degré zéro de l'argumentation ... qui à dit "troll" ? )
    • [^] # Re: Performances

      Posté par . Évalué à 4.

      Parce que le C c'est nul et les développeurs Gnome sont des cons.

      T'as une autre explication ?
      • [^] # Re: Performances

        Posté par (page perso) . Évalué à 10.

        Je sais que le but dans la vie ce n'est pas de se faire à tout prix des copains mais est-ce que tu pourrais, au minimum, arrêter d'employer perpétuellement un ton méprisant envers les autres ?

        Je suis un libriste mais je suis aussi un mec rationnel qui garde les yeux ouverts. Je sais faire un comparatif à la louche entre deux logiciels...ça tombe bien car j'utilise Ubuntu chez moi et XP au boulot.

        Comparons l'ouverture de deux gros répertoires.

        1) Si j'essaye d'ouvrir avec l'explorateur Windows le dossier system\win32 sur le portable du travail (DD 5400rpm) cela prend environ 3s pour avoir l'affichage.
        2) Si j'essaye d'ouvrir avec Nautilus le dossier /usr/bin sur le portable de la maison (DD 5400rpm) cela prend environ 74s pour avoir l'affichage !!!!!

        Ceci ne me gène pas énormément car je ne vais pas souvent visiter d'énormes dossiers comme /usr/bin mais cela démontre qu'il y a un gros problème avec Nautilus.
        • [^] # Re: Performances

          Posté par (page perso) . Évalué à 1.

          Pour la défense de Nautilus, on peut tout de même préciser, à l'inverse de l'explorer de Windows, qu'il analyse tous les fichiers du répertoire afin de pouvoir déterminer le type et t'afficher une belle icône (executable, perl, une miniature de l'img, etc etc).

          Pour avoir une idée, ça prend combien de temps pour l'explorateur de KDE d'afficher /usr/bin ?
          • [^] # Re: Performances

            Posté par . Évalué à 1.

            >> Pour avoir une idée, ça prend combien de temps pour l'explorateur de KDE d'afficher /usr/bin ?
            C'est si rapide que j'ai pas trop compté mais je dirais autour d'une seconde en tout cas moins de deux.
            Et ce quel que soit le mode d'affichage (il y en a une dizaine).
            (Machine achetée en Octobre et puissante)
            • [^] # Re: Performances

              Posté par (page perso) . Évalué à 1.

              Pour moi, sur une machine plus très récente mais pas mauvaise quand même, KDE prend 8 à 9 secondes pour afficher 2300 fichiers.
              Et si je le rouvre directement après, 0 secondes (il est donc dans le cache)
          • [^] # Re: Performances

            Posté par . Évalué à 2.

            Et si on ne veut pas qu'il analyse tout cela, il y a moyen de le désactiver ?
            • [^] # Re: Performances

              Posté par . Évalué à 1.

              Au pire tu peux prendre le source et recompiler ;)
          • [^] # Re: Performances

            Posté par (page perso) . Évalué à 4.

            >>> Pour la défense de Nautilus

            On parle quand même d'un temps d'ouverture de répertoire multiplié par vingt-cinq !!!
            Je comprends pas que les devs de Gnome ne se penchent pas sur ce problème.
            • [^] # Re: Performances

              Posté par (page perso) . Évalué à 2.

              En fait ils se sont penchés dessus, j'avais produit des tests de performance à ce sujet lors d'un "gnome love performance day" il y a un an, car le problème m'énervait également..

              http://bugzilla.gnome.org/show_bug.cgi?id=320282

              Depuis peu de choses ont changé on dirait, malheureusement. Je viens de demander des infos à ce sujet. Peut être peux tu reproduire mes tests sur ta machine, qui a un disque dur assez lent. Cela permettra peut être plus en évidence les accès I/O. Faire une trace avec sysprof est très facile (vraiment !). Contacte moi à liberforce at fr point st pour plus d'infos.
        • [^] # Re: Performances

          Posté par . Évalué à -5.

          > Je sais que le but dans la vie ce n'est pas de se faire à tout prix des copains mais est-ce que tu pourrais, au minimum, arrêter d'employer perpétuellement un ton méprisant envers les autres ?

          Car tu n'as pas été méprisant envers Gnome ? En lançant un troll à deux sous ?

          > XP au boulot.
          > ...
          > 1) Si j'essaye d'ouvrir avec l'explorateur Windows

          T'es au boulot le samedi matin ?

          > cela démontre qu'il y a un gros problème avec Nautilus.

          Ça ne serait pas encore du mépris ?
          Je connais mal windows et je n'utilise pas Nautilus.
          Mais sous Windows les icônes sans dans le programme. Sous Gnome ce n'est pas le cas.
          Sous windows pour le type du fichier, c'est l'extension qui est utilisé.
          Sous GNU/Linux, ça passe par magic(5).

          Autre chose, il y a beaucoup plus de fichier dans /usr/bin/ que dans system/win32.

          Et que disais-tu ?
          > Nautilus est-il si misérablement lent

          Misérablement lent !
          Ce n'est pas du mépris ça encore ?
          Mon /usr/bin/ qui est light a 1330 fichier. Ça prend 73 secondes selon toi, soit 18 fichiers par seconde. C'est ça misérablement lent ?

          > mais cela démontre qu'il y a un gros problème avec Nautilus.

          Fais un patch. (ton intentionnellement méprisant).
          • [^] # Re: Performances

            Posté par (page perso) . Évalué à 5.

            >>> Car tu n'as pas été méprisant envers Gnome ? En lançant un troll à deux sous ?

            En quoi est-ce méprisant que de signaler le fait que Nautilus est incroyablement lent quand on tente d'ouvrir /usr/bin ?
            En non ce n'est pas du mépris (venant de toi cette accusation serait presque drôle), c'est juste la constatation d'un fait.
            Si tu est content du fait qu'un processeur cadencé à 1,86 milliards d'instructions par seconde ne puisse afficher que 18 fichiers par seconde libre à toi. Pour ma part je constate que ce n'est pas le cas des autres explorateurs de fichiers (Konqueror ou l'explorateur Windows ou Dolphin que je viens d'essayer et qui affiche ce répertoire en 1s environ).

            >>> T'es au boulot le samedi matin ?

            En quoi ça te regarde ?
            T'a envisagé le fait que j'avais procédé à ce test avant d'écrire ce post dans ce journal ?
            • [^] # Re: Performances

              Posté par . Évalué à 0.

              > T'a envisagé le fait que j'avais procédé à ce test avant d'écrire ce post dans ce journal ?

              Oui.

              > Si tu est content du fait qu'un processeur cadencé à 1,86 milliards d'instructions par seconde ne puisse afficher que 18 fichiers par seconde libre à toi.

              Pour ton info, le problème (s'il y a) n'a rien à voir avec Nautilus :
              $ time file /usr/bin/*
              real 1m7.625s
              user 0m0.360s
              sys 0m0.350s


              T'as combien de fichier dans /usr/bin ?

              Et tu disais quoi de Nautilus. Je vais te raffraichir la mémoire :
              - "Nautilus est-il si misérablement lent"
              - "cela démontre qu'il y a un gros problème avec Nautilus"

              Tes affirmations ne tiennent sur rien.

              > Si tu est content du fait qu'un processeur cadencé à 1,86 milliards

              Et le temps d'accès à un fichier, ça prend combien de temps ? 10 ms au très très très minimum si les infos ne sont pas en cache. Soit au grand grand mieux 100 / s. Nautilus fait 18 /s c'est très bien. C'est n'est pas misérablement lent.
              • [^] # Re: Performances

                Posté par . Évalué à 6.

                Pour ton info, le problème (s'il y a) n'a rien à voir avec Nautilus :
                $ time file /usr/bin/*
                real 1m7.625s
                user 0m0.360s
                sys 0m0.350s

                Ben si, c'est Nautilus qui a choisi d'utiliser cette méthode (lente) qui n'est pas forcement adapter a ce que veut l'utilisateur (qui d'ailleur se fou du moyen utilisé).

                Et le temps d'accès à un fichier, ça prend combien de temps ? 10 ms au très très très minimum si les infos ne sont pas en cache.
                Ben essaye avec d'autres programe (comme readelf -h) et tu veras...
                Je ne parle meme pas de programme qui essayerais de faire des lecture asynchrone...
                • [^] # Re: Performances

                  Posté par . Évalué à 2.

                  > Ben si, c'est Nautilus qui a choisi d'utiliser cette méthode (lente)

                  C'est Unix qui a choisi cette méthode et elle est très bien.

                  > qui n'est pas forcement adapter a ce que veut l'utilisateur

                  l'utilisateur veut plus de 18 fichiers par seconde ?
                  Le problème n'est pas là. Il faudrait par exemple que nautilus mette à jours la fenêtre au fur et à mesure qu'il collecte des infos.

                  > Ben essaye avec d'autres programe (comme readelf -h) et tu veras...

                  Dans l'exemple précédent, file faisant l'affichage dans une xterm. Ce qui ralentit significativement file.

                  Après avoir vidé le cache :
                  $ time (readelf -h * > /dev/null 2>&1 )
                  real 0m21.763s
                  user 0m0.150s
                  sys 0m0.210s

                  Après avoir vidé le cache :
                  time (file * > /dev/null 2>&1 )
                  real 0m20.324s
                  user 0m0.360s
                  sys 0m0.360s

                  Cache plein :
                  $ time (readelf -h * > /dev/null 2>&1 )
                  real 0m0.287s
                  user 0m0.190s
                  sys 0m0.080s

                  Cache plein :
                  $ time (file * > /dev/null 2>&1 )
                  real 0m0.714s
                  user 0m0.410s
                  sys 0m0.250s



                  Et car tout ça commence à me casser les couilles, j'ai installé Nautilus.
                  Pour Nautilus si le cache est vidé j'ai 22 secondes, et si le cache est plein moins de 2 secondes.

                  Donc tout va absolument bien avec Nautilus et readelf n'est pas plus rapide que file ou Nautilus.
                  • [^] # Re: Performances

                    Posté par . Évalué à 2.

                    > Pour Nautilus si le cache est vidé j'ai 22 secondes, et si le cache est plein moins de 2 secondes.

                    $ rpm -q nautilus
                    nautilus-2.16.2-7.fc6
              • [^] # Re: Performances

                Posté par . Évalué à 4.

                Le coup du time, c'est ridicule.

                C'est clair qu'analyser 10000000000 de fichiers, ça prend du temps. Mais Nautilus n'affiche JAMAIS tous les fichiers en même temps. Donc techniquement, pour afficher la fenêtre, il lui suffit d'analyser les fichiers dont il va afficher les icones et c'est tout. Ensuite, s'il en a besoin, il peut analyser les autres fichiers.
                • [^] # Re: Performances

                  Posté par . Évalué à 2.

                  > Mais Nautilus n'affiche JAMAIS tous les fichiers en même temps.

                  Très juste. C'est ici qu'il faut travailler la question mais c'est loins d'être évident. Comme savoir ce qui doit être affiché avant d'avoir correcté les infos ?
                  C'est réalisable dans le mode liste. Chaque fichier occupe la même place dans la fenêtre. Donc si la scoll barre est à 54 % par exemple, on connait les fichiers qu'il faut examiné. Dans les autres modes, on ne sait pas.
                  • [^] # Re: Performances

                    Posté par . Évalué à 1.

                    Dans les autres modes, on ne sait pas.

                    Et bah on devrait. Et j'espère que les devs de gnomes en sont conscient.
                  • [^] # Re: Performances

                    Posté par . Évalué à 0.

                    Dans les autres modes, on ne sait pas.
                    ouch.

                    si c'est reellement le cas, ya la tete d'un designer d'IHM qui devrait tomber...

                    'fin ce que j'en dit, un soft de ce genre qui n'est pas capable de faire une correspondance vue/modele, ya un ENORME probleme dans l'equipe..
            • [^] # Re: Performances

              Posté par . Évalué à -2.

              > qui affiche ce répertoire en 1s environ

              Doit faire avec le "Windows touch" (c'est-à-dire n'utilise pas magic(5)). Si tu préfères Windows, prends Windows.
              • [^] # Re: Performances

                Posté par (page perso) . Évalué à 7.

                >>> Si tu préfères Windows, prends Windows.

                Je te jure c'est vraiment pénible ta mauvaise foi à toute épreuve.
                Est-ce que tu peux comprendre qu'il y a bien un problème spécifique à Nautilus mais que cela n'implique pas le moins du monde que je crache sur les devs de Gnome ?
                Je signale le problème c'est tout.

                Alors reprenons :

                Machine : Laptop Pentium M 1.86 GHz avec DD 5400 rpm
                OS : Ubuntu 6.10 Edgy
                Répertoire de test pour l'affichage : /usr/bin (1455 éléments)

                Test d'ouverture de ce répertoire (affichage en mode détails pour tous les logiciels) :

                Konqueror (version 3.5.5) => Temps d'ouverture : 1s pour l'affichage (env 10s pour que les icones spécifiques des fichiers finissent d'apparaitre).
                Dolphin (version 0.6.0) => Temps d'ouverture : 1s
                Thunar (version 0.4.1) => Temps d'ouverture : 21s
                Nautilus (version 2.16.1) => Temps d'ouverture : 76s

                Commentaires :
                * Dolphin est Thunar sont des logiciels non matures et en développement rapide. Pour bien faire j'aurai du utiliser les version SVN et non les paquets de ma distro qui sont déjà anciens (Thunar est actuellement en version 0.8 et Dolphin en version 0.8.2).
                * Tous ces logiciels affichent des icônes spécifiques selon le type de fichier sauf dolphin qui se contente d'afficher une icône standard.
                * Le problème de lenteur à l'affichage vient peut-être de GTK+ car Thunar a un temps d'ouverture assez long (mais comme c'est une version de dev très dépassée je ne connais pas la performance du Thunar actuel).
                * Nautilus a clairement un gros problème avec l'affichage des répertoires contenant beaucoup de fichiers. C'est d'autant plus grave qu'il est sensé être un logiciel mature à la différence de Dolphin ou Thunar.

                Screenshots des différents logiciels :
                Konqueror : http://www.flickr.com/photo_zoom.gne?id=433244344&size=o
                Dolphin : http://www.flickr.com/photo_zoom.gne?id=433244342&size=o
                Thunar : http://www.flickr.com/photo_zoom.gne?id=433244350&size=o
                Nautilus : http://www.flickr.com/photo_zoom.gne?id=433244348&size=o

                Conclusion :
                Est-ce que maintenant IsNotGood pourrait daigner accepter mon constat d'un problème existant dans Nautilus et cesser de crier au troll ?
                • [^] # Re: Performances

                  Posté par . Évalué à -4.

                  > Nautilus a clairement un gros problème avec l'affichage des répertoires

                  Pour les icons, Nautilus utilise SVG et c'est TRÈS BIEN. KDE 4 qui utilise SVG dit que ça impacte les performances. KDE 4 aura peut-être SVG, on va voir s'il est aussi rapide que Nautilus (ou selon ta terminologie aussi buggué que Nautilus).

                  Tu n'as avancé aucune évidence d'un gros problème ou bug alors que tu n'arrêtes pas de l'affirmer. Désolé si je suis méprisant, mais c'est tout ce que ton commentaire m'inspire.
                  • [^] # Re: Performances

                    Posté par (page perso) . Évalué à 6.

                    >>> Tu n'as avancé aucune évidence d'un gros problème ou bug alors que tu n'arrêtes pas de l'affirmer.

                    Je me casse le cul à te démontrer que Nautilus met 76 putains de secondes à afficher un répertoire et toi tu continue à puer de mauvaise foi et à ne rien faire d'autre qu'écrire et cracher sur les autres.
                    T'a fait quoi te ton coté pour constater ce problème ?
                    Pour toi ce n'est pas un gros problème que de voir tourner la petite animation d'attente pendant largement plus d'une minute alors que les explorateurs sous QT mettent une seconde ?

                    J'arrête là ce thread. On ne peux pas discuter avec un mec comme toi.
                    • [^] # Re: Performances

                      Posté par . Évalué à 0.

                      > toi tu continue à puer de mauvaise foi

                      J'ai dit que Nautilus était aussi rapide que le truc sous Windows ?
                      Non.
                      Toi tu affirmes qu'il y a un bug ou un gros problème Nautilus sans la moindre preuve.

                      Si tu veux dire que le mécanisme magic(5) est plus lent que d'utiliser les saloperies d'extension du nom de fichier, pas de problème, je suis d'accord, je l'ai déjà dit.

                      Mais sous Nautilus si je renomme "titi.jpg" en "titi.jpg.old", ça reste un fichier jpg et considéré comme tel. Si je renomme "titi.jpg" en "titi.exe" sous Nautilus ça ne se transforme pas en un programme. Sous Windows tu changes le type en changant son noom. C'est une aberration. Un fichier jpeg devient un fichier texte ou je ne sais quoi si tu le renomme *.jpg.old. Si tu double-cliques dessus Windows va lancer notepad ou je ne sais quoi mais un truc inadapté.

                      C'est n'est pas un gros problème ça ?

                      Autre truc. Sous Unix/Linux, les exécutable n'ont pas d'extension. Comme tu fais pour savoir si c'est un exécutable ? Car il n'y a pas d'extension ? C'est insuffisant. Il y a plein de fichier texte sous Unix/Linux sans extension par exemple (README, INSTALL, FAQ, NEW, etc...).
                      Autre problème. Il y a des fichiers avec les mêmes extensions mais qui ne sont pas du même type. Comme tu fais avec Windows ? Ben Windows affiche une boîte de dialogue pour choiser le programme qui va. Sous Nautilus ce n'est pas le cas.

                      Magic(5) n'est pas un problème ou un bug, magic(5) est la solution pour Unix.
                      Nautilus utilise ce qui est adapté pour Unix et ce n'est pas de la faute à Nautilus, ce n'est pas un gros bug Nautilus. Et te n'a en rien démontré le contraire.

                      Tu m'insultes de mauvaise fois (m'enfin c'est à la mode avec moi quand il n'y a plus d'argument), mais toi que fais tu ?
                      Tu fais des affirmations, des accusations de gros problèmes ou bugs, et ce sans la moindre preuve, sans le moindre semblant de réflexion.

                      > Pour toi ce n'est pas un gros problème

                      Je n'ai jamais dit que la lenteur de magic(5) n'était pas un problème. Quelqu'un propose une solution dans le cas de Nautilus (n'examiner que les fichiers affichés et je l'appuis à 100%). Par contre je dis et je répète que Nautilus n'a pas de gros problèmes ou bugs.
                      La solution de Windows a aussi des gros problèmes. Tu n'aurais pas remarqué ?
                      Par exemple sous Windows le type du fichier est dans le nom du fichier. Le concept est si pourri que par défaut Windows ne permet pas de changer tout le nom du fichier. Je dis que ce concept est pourri, je ne dis pas que le file manager de Windows (ou dauphin, etc...) a un bug.

                      > Nautilus met 76 putains de secondes à afficher un répertoire

                      Et dans quelles conditions ? Car tu va ouvrir /usr/bin que la majorité des gens ne vont pas ouvrir. Pour lancé un programme, c'est le menu gnome qu'il faut utiliser et qui est utilisé dans 99,9 % des cas.
                      Vu le temps que ça te prend, il doit y avoir 2000 fichiers dans ton /usr/bin. Es-ce un cas classique d'utilisation d'un file manager ? Les files manager sont pour $HOME à 99 %. Les cas où on va snifer /usr/bin, c'est dans 99 % des cas pour troller sur Nautilus.

                      > alors que les explorateurs sous QT mettent une seconde ?

                      Ce qui n'a rien à voir avec le toolkit graphique.
                      Je te laisse à tes trolls.
                      • [^] # Re: Performances

                        Posté par . Évalué à 5.

                        J'ai fait le test chez moi avec un nautilus 2.14.3 (debian unstable) et il met bien plus de 30 sec pour afficher la première icone d'un /usr/bin de 2581 fichiers (sur un ibook G4/1GHz). Utiliser la complétition automatique du file-chooser dans /usr/bin est inutilisable. Même si l'intérêt est quasi nul dans ce cas, je peux facilement imaginer quelqu'un possédant un répertoire contenant plus de mille fichiers.

                        Alors que faire un magic sur les fichiers soit lent, c'est compréhensible. Mais ce n'est pas une raison pour ne pas savoir le faire de façon asynchrone. Nautilus devrait pouvoir afficher plus rapidement le contenu de la fenêtre (24 icones dans mon cas, soit <1% du répertoire) et les redissiner au fur et à mesure que magic fasse son travaille (inutile aussi de "magicifier" les fichiers non-affichés).

                        Sur ce, on peut troller sur le fait que ce travaille d'optimisation n'a pas été fait parce qu'il serait plus difficile de retravailler cet algo dans un programme en C mais c'est une autre histoire...
                        • [^] # Re: Performances

                          Posté par . Évalué à 1.

                          > Nautilus devrait pouvoir afficher plus rapidement le contenu de la fenêtre (24 icones dans mon cas, soit <1% du répertoire) et les redissiner au fur et à mesure que magic fasse son travaille (inutile aussi de "magicifier" les fichiers non-affichés).

                          http://linuxfr.org/comments/815651.html#815651 (c'est de moi).

                          > Sur ce, on peut troller sur le fait que ce travaille d'optimisation n'a pas été fait parce qu'il serait plus difficile de retravailler cet algo dans un programme en C mais c'est une autre histoire...

                          Le C ça pue. Quel catastrophe que le C soit le language le plus utilisé dans le libre. Je n'ose imaginer comme le noyau Linux serait merveilleux s'il était codé avec un vrai language d'homme comme le C++.
                          Tous des tarlouse les développeurs noyaux.
                          • [^] # Re: Performances

                            Posté par . Évalué à 3.

                            Merci de re-re-renter dans le troll (j'avais prévenu pourtant) :-)
                            Merci aussi de comparer des pommes et des poires (c'est sûr qu'un noyau et un toolkit ont les mêmes impératifs...).

                            Si tu veux, tu peux comparer GTK à FLTK qui est très bien, parait-il (je ne l'ai jamais utilisé, le c++ c'est beurk pour moi). Où alors linux v2.2 avec BeOS.
                      • [^] # Re: Performances

                        Posté par (page perso) . Évalué à 4.

                        Bon, et si c'est alan cox qui dit qu'il y a une merde là dedans, au moins, lui tu le crois :

                        http://linuxfr.org/2001/08/26/4667.html

                        (putain, 2001, et rien a évolué. Je croyais que les logiciels libres avaient l'avantage de la réactivité ...)
                • [^] # Re: Performances

                  Posté par . Évalué à -1.

                  > Est-ce que maintenant IsNotGood pourrait daigner accepter mon constat d'un problème existant dans Nautilus et cesser de crier au troll ?

                  Non.
                  Et c'est toi qui troll.
                  Trouve un file manager qui utilise magic(5) (c'est bien) et SVG (c'est bien) qui va plus vite que Nautilus si tu veux arrêter de troller.
                  • [^] # Re: Performances

                    Posté par . Évalué à 3.

                    Le problème ne vient pas de l'utilisation de magic, mais de la façon dont l'affichage se fait : konqui par exemple prend énormément de temps à détecter le type de fichier et à génerer les thumbs des images, fichiers pdf, etc... (si ils ne sont pas déjà en cache bien sur). Néanmoins quand j'ouvre un répertoire, il m'affiche instatanément son contenu, et ensuite remplace petit à petit les icones par les thumbs, et ce en priorité pour les fichiers affichés dans ma fenêtre. Du coup ça parait quasi instantané, alors qu'au final il prend surement autant de temps que n'importe quel autre filemanager pour réaliser l'opération complète.

                    Donc moi je suis également assez daccord pour dire que pour un navigateur de fichier, c'est un gros problème.
                • [^] # Re: Performances

                  Posté par . Évalué à 2.

                  Juste pour donner le temps (en gros) chez moi avec Thunar 0.8: ça met environ 2sec.

                  Il y a une amélioration notable des temps d'ouverture avec cette version 0.8 (bon je n'ai pas vérifié si le cache était vide ou pas vu que j'avoue ne pas trop savoir vers où regarder), mais en tous cas ça ne prend plus 20sec comme avant.
    • [^] # Re: Performances

      Posté par . Évalué à 8.

      Mon Konqueror fonctionne vite. Il est surement écrit en C...

      PS : Je demande l'indulgence, on est toujours vendredi.
      • [^] # Re: Performances

        Posté par . Évalué à 2.

        Je n'accuse pas le C++ de piètre performance, (y'a pas d'interprêteur ni de machine virtuelle). Parcontre, pour les passerelles vers d'autres langages, c'est pas au niveau de GObject.

        Bref, C++ c'est (très) bien, mais àmha pas si on veut aussi coder en python, ruby, perl, avec la même bibliothèque.

        Étienne
        • [^] # Re: Performances

          Posté par (page perso) . Évalué à 4.

          enfin c'est surtout que coder en GObject ça pue donc tout le monde préfère coder les applis en python, ruby (ça c'est en langage qu'il est bien) ou perl

          Mais quand on a gouté à qt, au model objet et surtout à la cohérence de l'ensemble ben y'a pas photo, ça marche bien, vite et ça se code assez facilement, que du bonheur (note : j'ai surtout touché à qt4, le 3 je connais moins)
        • [^] # Re: Performances

          Posté par . Évalué à 2.

          Gtk et le langage C, c'est pas cette lib avec laquelle on simule l'héritage avec des cast de structure, cette lib avec laquelle on caste des void* pour simuler le polymorphisme, cette lib avec laquelle on ne dispose pas de l'héritage virtuel des opérations et avec laquelle les contrôles de types sont confiés aux programmeur.
          Gtk c'est pas cette lib que l'on a wrappé avec Gtkmm pour pouvoir l'utiliser convenablement avec un vrai langage objet.
          Bref une lib objet qui oblige les programmeurs à les implementer au lieu de s'appuyer sur un langage adapté.

          Bon bah vaut mieux utiliser QT ou Fox alors
          http://www.fox-toolkit.org/
          • [^] # Re: Performances

            Posté par . Évalué à 3.

            Gtk c'est pas cette lib que l'on a wrappé avec Gtkmm pour pouvoir l'utiliser convenablement avec un vrai langage objet.

            Non, on l'a wrappée avec Gtkmm pour qu'on puisse l'utiliser avec C++. Pour l'utiliser avec de vrais langages, on l'a wrappée sur Ruby, Python, OCaml, Eiffel (un peu), ...
            Et aussi sur Perl, PHP, Java, C#...
            Et probablement Lisp, Ada, et tous les autres.

            Bouh, que c'est mal, cette lib qu'on peut utiliser avec le langage de haut niveau de son choix. Y compris ceux qui te donnent de l'héritage, du vrai polymorphisme et qui contrôlent les types à ta place. C'est quand même très fort de réussir à présenter ça comme un défaut.
            • [^] # Re: Performances

              Posté par . Évalué à 3.

              > Bouh, que c'est mal, cette lib qu'on peut utiliser avec le langage de haut niveau de son choix.

              Et ces salops ils le font aussi pour libgnome, gconf, gnome-vfs, etc...
              Aucune morale.
            • [^] # Re: Performances

              Posté par . Évalué à 1.

              C'est pas mal, c'est juste que c'est contre-productif.

              Des wrapper pour Qt, tu en a dans tous les langages aussi (rubyqt, pyqt, Qt Jambi, ...)mais au moins ils ont utilisé un langage d'implémentation qui les supporte plutôt que de les réinventer.
              Bref, utiliser un langage procédural pour faire de l'objet c'est à peu près aussi malin que d'utiliser un marteau pour enfoncer une vis.
              • [^] # Re: Performances

                Posté par . Évalué à 1.

                > Bref, utiliser un langage procédural pour faire de l'objet c'est à peu près aussi malin que d'utiliser un marteau pour enfoncer une vis.

                Le C++ est aussi traduit en procédural. Il n'y a pas de CPU qui font de l'objet.
                Utiliser C++ c'est comme "utiliser un marteau pour enfoncer une vis" ?
                • [^] # Re: Performances

                  Posté par . Évalué à 3.

                  Personne ne code en "C++ traduit en procédural", c'est le compilo qui fait ça. Et quand tu codes en C++, tu ne te soucie pas de comment le compilo va faire son boulot.

                  Quand tu codes en C/Gobject, tu te soucie de "comment coder de l'objet en procédural"
                  • [^] # Re: Performances

                    Posté par . Évalué à 1.

                    > c'est le compilo qui fait ça.

                    C'est gobject qui fait ça.

                    > Et quand tu codes en C++, tu ne te soucie pas de comment le compilo va faire son boulot.

                    Quand tu codes en C++ avec gtkmm, tu ne te soucie pas de comment le compilo va faire son boulot et comment c'est linker avec gobject.


                    C'est mignon comme type de réflexion mais ça ne va pas loins. Un programme C++ utilise la libc (c'est du procédurale), un programme Qt utilise libx11 (c'est encore du procédurale), un autre va utiliser dbus, etc...
                    Les trucs 100 % C++ ça n'existe pas.
                    • [^] # Re: Performances

                      Posté par . Évalué à 2.

                      C'est mignon comme type de réflexion mais ça ne va pas loins. Un programme C++ utilise la libc (c'est du procédurale), un programme Qt utilise libx11 (c'est encore du procédurale), un autre va utiliser dbus, etc...
                      Les trucs 100 % C++ ça n'existe pas.


                      Quand tu codes en C++, tu te fiches de la libc, quand tu codes en Qt, tu te fiches de la libx11. D'ailleurs QT n'utilise pas forcément la libx11, sous windows par exemple.

                      Les langages objets te permettent d'utiliser la POO sans te poser trop de question. Le C c'est déjà plus tendu, plus tricky pour implémenter de l'objet. Pourquoi vala sinon ?
                      • [^] # Re: Performances

                        Posté par . Évalué à 1.

                        Il fait semblant de ne pas comprendre , je crois.
                        Je lui conseille la lecture de cet excellent livre pour comprendre en quoi le lange C n'est pas adapté pour la POO
                        http://www.planetpdf.com/developer/article.asp?ContentID=663(...)
                        • [^] # Re: Performances

                          Posté par . Évalué à 1.

                          > comprendre en quoi le lange C n'est pas adapté pour la POO

                          T'es gentil, je le sais. Je n'ai jamais dit de faire du C++ avec du C (t'as remarqué le quasi non sens de cette phrase ?).
                          Mais tu peux faire du java ou du python ou du C++ avec gtk+ qui est codé en C. Il y a des wrappers pour ça et ça marche bien.

                          C'est bien gentil de troller avec des "gtk c'est pas du C++" mais gtk a plein de wrappers qui marchent.
                          Le sénario où pour chaque fonctionnalités il faut la coder dans chaque language est une aberration (ça demande énormément de développeurs).

                          Il y a un wrapper de X11, libxml2, gstreamer, postgresql, etc pour C++ (par exemple Qt) et on trouve ça très bien. Et je trouve ça très bien.

                          Il y a la même chose pour gtk+ (et pas seulement pour le C++) et je ne vois pas pourquoi ça ne serait pas bien.

                          C'est tout ce que je dis. Je ne dis pas de faire du C++ avec du C.
                          Mais la concèption de gtk pour faire des bindings vers d'autre language est un avantage définitif et pas une faiblesse.
                          Gtk n'a pas essayé de faire du C++ avec C, mais de permettre facilement des binding. Et c'est bien™.

                          Si Gtk avec un wrapper C++ est une connerie, alors pourquoi personne n'a recodé libxml2 en C++ par exemple ?
                          Pourquoi il n'y a pas un libX11 en C++ mais seulement des wrappers ? Pourtant c'est tout à fait possible. Pourquoi pas de libX11 en pure python ? C'est aussi tout à fait possible.

                          Je trouve ça marrant ces critiques des wrappers de gtk+ alors que c'est fait pour plein de librairies.

                          Rappel : gtk+ n'a pas été faite pour être utilisable uniquement avec C. Les faits montrent que c'est une réussite.
                          • [^] # Re: Performances

                            Posté par . Évalué à 3.

                            l'envie de nourrir le troll m'est venu,

                            Faire une lib avec une interface C pour la portabilité c'est bien, vue que n'importe quel langage a une glue pour le C.

                            Vouloir refaire de l'objet en C pour faire un un truc aussi attractif niveau programation que gtk, c'est une perte de temp

                            Je pense que vala est la preuve que la maniere dont a été développé GTK a été une erreur technique. Refaire un langage haut niveau qui génére du C GObject aurait du ètre la premiere etape de GTK , pas la derniere.

                            Quand je vois les possibilité offert au niveau toolkit graphique tel que swing (java), notament gnu classpath, et ce qu'offre GTK, ben je trouve autrement plus efficace de faire et etendre des widget en java qu'en GTK.

                            le C c'est bien pour faire des truc bas niveau ou trés limité (libX11, libxml2) mais je ne classe pas les interface graphique dans cette catégorie.

                            Les vrais langage objet sont bien plus facile a utiliser pour faire cela et vouloir programmer un toolkit graphique directement en C est AMHA un mauvois choix technique.

                            Ensuite si il l'avait fait en java qui sort du C je dirais pas, mais l'efficacité du C est moins bonne, sinon on aurais encore des compilo C++ qui génerais du C , comme au début, mais plus le langage est riche, plus on peut faire d'optimisation au niveau du compilateur et se concentrer sur des truc plus utile comme le framework, les algorithme, la concurence (comme avoir un thread d'affichage, un de collecte d'info de base et un de collecte d'info avancé).
                            • [^] # Re: Performances

                              Posté par . Évalué à 2.

                              je trouve autrement plus efficace de faire et etendre des widget en java qu'en GTK


                              Je suppose que tu parles de GTK en C, parce qu'étendre un widget GTK en Ruby se fait de la même manière qu'en Java: tu dis de quel widget tu hérites et tu modifies les méthodes qui changent.

                              Par contre en C c'est pénible, c'est sûr.
                              • [^] # Re: Performances

                                Posté par . Évalué à 1.

                                Je suis tous a fait d'accord,

                                Le commentaire pour l'extensions des widgets est surtout orienté extensions dans la lib, i.e plus de feature dans la lib.

                                Par exemple un menubar++ qui permet de changer l'orientation des menus,
                                ou autre truc bizzares,
                                Si c'est vraiment utile c'est mieurx de l'avoir dans la lib que de tout recoder dans chacun des langages cibles,
                                mais un truc que tu peut faire en 5 min en langage haut niveau, tu risque de mettre 1 semaine a le faire en C, avec plein de bugs.


                                C'est la ou le choix du C en tant que langage pour faire un toolkit graphique risque de limiter les évolutions des feature du tooklits.
                            • [^] # Re: Performances

                              Posté par . Évalué à 1.

                              > Je pense que vala est la preuve que la maniere dont a été développé GTK a été une erreur technique. Refaire un langage haut niveau qui génére du C GObject aurait du ètre la premiere etape de GTK , pas la derniere.

                              Plusieurs années après la sortie de gtk2, c'est facile à dire...
                              M'enfin tu montres que GObject est une bonne chose.

                              N'hésites à recoder gtk en vala si ça te chante. Bon courage. N'oublie pas de conserver des performances correctes.

                              > Quand je vois les possibilité offert au niveau toolkit graphique tel que swing (java), notament gnu classpath, et ce qu'offre GTK, ben je trouve autrement plus efficace de faire et etendre des widget en java qu'en GTK.

                              Bizarre, eclipse utilise gtk. Dans 7 ou 8 ans je pense que tu vas faire la leçon à eclipse.

                              > Quand je vois les possibilité offert au niveau toolkit graphique tel que swing (java)

                              Pour ton info, Java (la version officielle) utilise gtk pour swing :
                              http://ensode.net/java_swing_mustang_screenshots_gtk.html

                              M'enfin, c'est encore moi qui trolle, qui suit de mauvaise fois, etc...

                              > le C c'est bien pour faire des truc bas niveau ou trés limité (libX11, libxml2) mais je ne classe pas les interface graphique dans cette catégorie.

                              Et gdk ? Et pango ?
                              Il y a des aspects critiques en performance dans gtk (les grosses listes, le positionnement des widgets, le calcul de la taille sur l'écran d'une chaine, l'affichage en fonction du thème, etc). Regardes java, etc, pour le toolkit il passe par gtk ou équivalent.
                              Un toolkit écrit uniquement en java ou python serait une catastrophe niveau performance. J'en suis à 100 % convaincu.

                              Coder l'utilisation d'un toolkit peu raisonnablement se faire avec un language de haut niveau type java/python/etc.
                              Coder le toolkit, j'y crois pas. Et d'ailleurs ça ne c'est jamais vu. Du moins je ne l'ai jamais vu.

                              Pour info, swing n'est pas écrit uniquement en java. Il est aussi écrit en C.
                              • [^] # Re: Performances

                                Posté par . Évalué à 1.

                                Tu peut m'expliquer (ou filer des pointeurs) pourquoi GObject est une bonne chose?
                                Desc comparaisons de performance sur l'héritage, les possibilité de polymorphisme, la facilité d'écriture en GObject + C ?

                                Pour ce qui est de dire que GTK c'est bien parceque SWT l'utilise, je voudrais faire remarquer que motif a des tonnes de features super avancé, la preuve eclipse utilise motif, avec eclipse et motif tu peut faire des widget super génials....

                                Pareil pour swing et GTK, swing (qui utilise AWT si mes souvenirs sont exactes) peut aussi utiliser plusieurs toolkit, dont GTK.

                                Ton lien est en effet trés intéressant, les gens sont content parceque swing va avoir une apparence comme GTK.

                                Bref des toolkit multiplateforme peuvent utiliser GTK, cela ne veut pas dire que GTK fournit tout ce que fournit le toolkit qui l'utilise pour le dessins.

                                Pango c'est pas fait pour dessiner des polices? GDK c'est pas une lib pour dessiner?
                                Si oui ce sont en effet des éléments d'un toolkit graphique, mais un toolkit graphique c'est plus que ca, c'est plutot des collection d'elements graphique et la maniere de les faire interagir.

                                mais bon, j'ai assez nourris le troll, le

                                Coder l'utilisation d'un toolkit peu raisonnablement se faire avec un language de haut niveau type java/python/etc.
                                Coder le toolkit, j'y crois pas. Et d'ailleurs ça ne c'est jamais vu. Du moins je ne l'ai jamais vu.



                                me fait douter, j'ai jamais vu des gens coder l'utilisation d'une interface en C.
                                mes si tu est sur a 100% , que tu y croit, ou pas d'ailleur, comme tu veut mais c'est pas ce que j'appelle un argument technique.

                                Si coder un toolkit en java c'est du jamais vu, je te conseille awt ou swt.
                                On peut meme coder des micro-kernel en C++, L4Ka::Hazelnut, voir en java (sur des proc java pourquoi pas).
                                • [^] # Re: Performances

                                  Posté par . Évalué à 1.

                                  > Tu peut m'expliquer (ou filer des pointeurs) pourquoi GObject est une bonne chose?

                                  Non, c'est que de la connerie. GObject c'est une daube.

                                  > Desc comparaisons de performance sur l'héritage, les possibilité de polymorphisme, la facilité d'écriture en GObject + C ?

                                  Ça pue GObject. Une perte de temps et en plus ça fait un trou dans la couche d'ozone.

                                  > Pour ce qui est de dire que GTK c'est bien parceque SWT l'utilise

                                  Ouais, mais les connards derrières eclipse, java et swing sont passés à gtk.
                                  Franchement, la planète est peuplée de connards

                                  > je voudrais faire remarquer que motif a des tonnes de features super avancé, la preuve eclipse utilise motif, avec eclipse et motif tu peut faire des widget super génials....

                                  Mais t'as raison, Motif roxor.
                                  M'enfin l'humanité n'est pas encore prête et Motif est abandonné. Faut prévoir son retour au 31ième siècle quand on aura tous un QI de 400. Trop tard pour moi, c'est con.

                                  > la preuve eclipse utilise motif

                                  Malheureusement pas pour longtemps. C'est seulement un option pour ceux qui ont su reconnaitre l'immense supériorité de Motif sur Gtk.
                                  Il faut en profiter un max avant que gtk pourrisse eclipse définitivement.

                                  > Pareil pour swing et GTK, swing (qui utilise AWT si mes souvenirs sont exactes) peut aussi utiliser plusieurs toolkit, dont GTK.

                                  Pire que ça, il va utiliser gtk par défaut. Une horreur. En trois mots : une catastrophe industrielle.

                                  > Bref des toolkit multiplateforme peuvent utiliser GTK, cela ne veut pas dire que GTK fournit tout ce que fournit le toolkit qui l'utilise pour le dessins.

                                  T'as raison, swing qui utilise gtk par défaut c'est un bon de 10 ans en arrière.

                                  > j'ai jamais vu des gens coder l'utilisation d'une interface en C.

                                  Ça doit être une légende alors. Et je ne l'ai jamais fait (pour moi : passer à corriger mon C.V.).
                                  $ repoquery --whatrequires --queryformat="%{NAME}\n" libgtk-x11-2.0.so.0 | sort | uniq | wc -l
                                  578

                                  Merde, il doit y avoir un bug dans repoquery

                                  > Si coder un toolkit en java c'est du jamais vu, je te conseille awt ou swt.

                                  Swt utilise gtk il ne recode pas tout le toolkit. Ou alors c'est une légende ? Pour awt, je n'en sais rien.

                                  > On peut meme coder des micro-kernel en C++, L4Ka::Hazelnut, voir en java (sur des proc java pourquoi pas).

                                  On peut. Quelle dommage que le dictateur Linus Torvalds ait choisi le C.
                                  • [^] # Re: Performances

                                    Posté par . Évalué à 1.

                                    Donc si swing utilise GTK directement, tous ce qui est disponible dans swing l'est forcement dans GTK non?
                                    Le dialogue d'ouverture de fichier est donc le meme, on peu editer du RTF, parser du HTML avec exactement les mem fonctionalité avec GTK?


                                    Si tu sait coder l'utilisation d'une interface en C ca m'interesse pour mes tests, c'est super pratique pour detecter les bug d'utilisation d'interface.

                                    Ton argument c'est que un ou plusieurs toolkit de haut niveau (SWT;Swing) utlisent GTK, donc GTK c'est bien.

                                    Ma remarque c'est que ces toolkits haut niveau utilisent les fonctions les plus basiques des toolkits systèmes,
                                    les fonctionalité importante du toolkit (widget, architecture et API) sont recodé au dessus et n'ont rien a voir avec le toolkit de base.

                                    Mais bon je te conseille vraiment de corriger to CV,
                                    parceque coder l'utilisation d'une API c'est plutot décrire comment utiliser une API,
                                    ca ressemble a des pre-condition, post-condition, comportement de l'interface, ... etc

                                    De plus les seuls arguments avancé c'est "je peut voir des boutons GTK avec eclipse, GTK c'est bien"
                                    C'est pas trés convainquant pour les capacité de recherche, d'analyse et de synthèse d'un Pb.

                                    Je ne corrige pas de CV, mon orthographe est trop lamentable pour ca.
                                  • [^] # Re: Performances

                                    Posté par . Évalué à 2.


                                    Tu peut m'expliquer (ou filer des pointeurs) pourquoi GObject est une bonne chose?

                                    ... Ouais, mais les connards derrières eclipse, java et swing sont passés à gtk.
                                    Franchement, la planète est peuplée de connards


                                    Belle argumentation technique sur les qualités de GObject.
                                    Tu m'impressionnes chaque jour un peu plus


                                    > je voudrais faire remarquer que motif a des tonnes de features super avancé, la preuve eclipse utilise motif, avec eclipse et motif tu peut faire des widget super génials....

                                    Mais t'as raison, Motif roxor.
                                    M'enfin l'humanité n'est pas encore prête et Motif est abandonné. Faut prévoir son retour au 31ième siècle quand on aura tous un QI de 400. Trop tard pour moi, c'est con

                                    Sauf que le mr te repondais sur le fait que ce n'est pas parce que Eclipse utilise Gtk que c'est un gage de qualité. Motif aussi donc selon tes arguments Motif dechire forcément. Merci de demonter ton raisonnement par la dérision à sa place


                                    Bref des toolkit multiplateforme peuvent utiliser GTK, cela ne veut pas dire que GTK fournit tout ce que fournit le toolkit qui l'utilise pour le dessins.

                                    T'as raison, swing qui utilise gtk par défaut c'est un bon de 10 ans en arrière.

                                    Tu relis ce à quoi tu réponds des fois. que gtk ou n'import quel lib soit utilisée importe peu puisque c'est les primitives bas niveau qu sont utilisées. Les Widgets et autres layout qui dechirent sont tous réimplémentés dans SWT/JFace.


                                    > Si coder un toolkit en java c'est du jamais vu, je te conseille awt ou swt.

                                    Swt utilise gtk il ne recode pas tout le toolkit. Ou alors c'est une légende ? Pour awt, je n'en sais rien.

                                    Non mais que ce soit AWT ou SWT la réutilisation est mince. Même si AWT utilise encore moins les services du tk hôte que SWT.
                                    http://www.jguru.com/faq/view.jsp?EID=507891
                                    Ceci aurait tendance à me conforter dans l'idée que GTK n'est pas un foudre de guerre quand on compare les perfs d'eclipse sous Win32 ett Gtk. L'appoche AWT est encore pire mais ca ne dédouane pas Gtk pour autant. On sait pourquoi ca rame alors qu'avec SWT/gtk il y a de quoi se poser la question.
                              • [^] # Re: Performances

                                Posté par . Évalué à 3.


                                Bizarre, eclipse utilise gtk. Dans 7 ou 8 ans je pense que tu vas faire la leçon à eclipse.

                                Eclipse utilise SWT qui n'utilise que quelques primitives graphiques d GTK.
                                Il y a eu un port de SWT vers Qt mais ce qui posait pb etait la license à l'époque.
                                D'ailleurs, en comparant les perf d'eclipse sous windows et sous Linux on se dit que GTK n'a pas de quoi pavoiser.
                                • [^] # Re: Performances

                                  Posté par . Évalué à 2.

                                  Bon concernant les perfs je retire ce que j'ai dit parce qu'il n'y a pas que la lib qui intervient. L'implementation de la JVM doit y être pour beaucoup. Faudrait tester en compilé pour mieux se rendre compte.
                                  • [^] # Re: Performances

                                    Posté par . Évalué à -2.

                                    Je valide, pour avoir benche differentes jvm (sun/ibm sous windows/linux), la jvm sun pour linux est une daube sans nom.

                                    Et je valide aussi qu'eclipse linux est d'une lenteur sans non sur ma babasse perso (athlon 1600+XP/768Mo ram) alors qu'il tourne plus que decemment sur un windows sur la meme machine.
                                • [^] # Re: Performances

                                  Posté par . Évalué à 0.

                                  pour etre tout a fait exhaustif : SWT est porte pour GTK et Motif.
                                  Et aussi pour win32 (trou de memoire pour le nom de l'api) et aqua ('fin le machin de chez appeule)

                                  Et il ne s'en sert effectivement que pour les primitives graphiques, toute l'ihm derriere et faite en java.
                            • [^] # Re: Performances

                              Posté par . Évalué à 3.

                              De façon général, ça fait depuis des années que ça trolle sur gtk, que c'est pourri, que GObject c'est de la connerie, que l'utilisation du C est une aberration, etc...

                              Ben gtk est le toolkit de référence sous Unix. Utilisé par Java, Gnome, eclipse, XFCE, OOo, Mozilla (firefox etc), gimp, Inkscape, etc...
                              Vient après Qt en popularité. Je ne dit pas que Qt est moins bien, mais le gros atout de gtk par rapport à Qt c'est ses bindings.

                              Dans 10 ans ça continura de troller.
                              • [^] # Re: Performances

                                Posté par . Évalué à 3.

                                Regarde plus du côté de la licence que du côté des qualités techniques pour expliquer sa popularité. Personnellement, sur mes ordinateurs, c'est bien sûr QT qui est le plus populaire, et de très loin.
                              • [^] # Re: Performances

                                Posté par . Évalué à 3.

                                Ben gtk est le toolkit de référence sous Unix. Utilisé par Java, Gnome, eclipse, XFCE, OOo, Mozilla (firefox etc), gimp, Inkscape, etc...


                                Swing (java) et VCL (OpenOffice) utilise GTK?
                              • [^] # Re: Performances

                                Posté par (page perso) . Évalué à 4.

                                Ouais, et windows est largement plus utilisé que linux, preuve de sa grande supériorité technique...
                            • [^] # Re: Performances

                              Posté par . Évalué à 4.

                              Les interfaces en Java, c'est une vrai plaie ! Rien que ces listeners c'est pourri comparé aux signaux de Gtk+ et aux slots de Qt.

                              T'es pas obligé d'étendre ton Widget en C, tu peux le faire dans n'importe quel langage ayant une passerelle vers C/GObject. Évidemment, ce sera plus dur d'exposer ton super nouveau Widget vers d'autre langage une fois que t'aura choisie python ou ruby.

                              C'est d'ailleur pour ça que j'utilise C/GObject directement pour gnome-scan, je veux un bindings python, C++, perl, ruby, … et un vapidef :)

                              Étienne
                          • [^] # Re: Performances

                            Posté par . Évalué à 3.

                            Arrrêtes ta mauvaise foi.
                            On ne critique pas le C.

                            Ce qu'on t'explique c'est que coder un tk graphique qui sous-tend des concepts résolument objets avec un langage qui ne l'est pas est une mauvaise stratégie.

                            T'as beau invoquer Linus, libx11 et toutes les libs de bas niveau C de Linux/X11.
                            Leur conception n'est pas objet donc il n'y a pas de raison d'utiliser le C++.

                            Peu importe qu'il y ait des bindings. Personne ne le conteste mais
                            le langage d'implementation par défaut conditionne le reste.
                            On va pas se taper toutes les libs et tous les interpréteurs de la création pour implementer la lib GTK (sinon bonjour les dépendances). On utilise UN langage et on permet aux applis clientes d'utiliser leur propres langages pour communiquer. C'est le minimum attendu et je vois pas en quoi Gtk serait plus une réussite à ce niveau que Qt ou les ports pour Gnustep.

                            Ce qu'on t'explique c'est qu'il faut utiliser le bon outil pour la bonne tâche. Si t'en es là pourquoi ne pas recoder le kernel entièrement en assembleur plutôt que certaines parties incoutournables. Aucun doute c'est un vrai langage qui roxor sa mère.

                            Et c'est pareil pour les exemples avec Swt / Swing et wxWidgets
                            Ces libs sont bien obligées de s'appuyer sur les primitives graphiques de l'OS (GDI pur Windows et gtk pour linux) . C'est le minimum. Mais pour le reste c'est à dire l'essentiel c'est implenté complétement avec un langage ... objet. Pareil pour wxWidget, Fox, XPToolkit, Gnustep, ... Quasiment tous les tk modernes utillisent un langage objet. Seul les viellissants Motif, GDI et OS/2 PM avaient fait ce choix maias pour combien de temps. OS/2 est mort, Motif agonisant et MS tente le virage C# mais recule devant l'ampleur des dégats.
                            http://www.free-soft.org/guitool/

                            Je vais arrêter là car tu vas encore nous ressortir les mêmes pseudo contre exemples et on va tourner en rond.
                            • [^] # Re: Performances

                              Posté par . Évalué à 3.

                              > Ce qu'on t'explique c'est que coder un tk graphique qui sous-tend des concepts résolument objets avec un langage qui ne l'est pas est une mauvaise stratégie.

                              Très bien, mais j'ai dit plus 400 000 fois que la force de gtk est ses bindings.
                              Si pas de binding, le C++ c'est mieux.
                              En passant, je développe aussi en C++ et je préfère le C++ au C.
                              Mais le fait que je préfère le C++, que le C++ soit supérieur au C, n'est pas un raison que gtk a eu tord d'être écrit en C. Gtk n'a pas été écrit en C pour l'amour du C mais pour avoir les binding.

                              Alors vous pouvez continuer à dire que gtk en C c'est une connerie, mais les faits sont là : gtk a des binding, beaucoup, et ils marchent bien.

                              Qt a quelques bindings avec un ou deux qui marchent bien.

                              Si un des principaux objectifs est d'avoir des bindings, gtk a eu raison d'être écrit en C, de faire GObject, etc... Les faits le démontre.

                              > Leur conception n'est pas objet donc il n'y a pas de raison d'utiliser le C++.

                              Tu t'emballes un peu. Certe libX11 n'est pas libXt, mais l'idée est là.

                              C'est Kernighan qui disait que tout bon programme C est orienté object. Du montant que tu as des structures et que tu y associés des fonctions (de façon directe ou non avec les pointeurs de fonction, en utilisant des types, etc) c'est de la programmation object. Ou dit que c'est de l'encapsulation de données si ça vexe ta haute idée de la POO.

                              En passant, la POO n'est pas réservée à aux languages dédiés POO. Linux est un assez bon exemple de POO. Lis les sources pour t'en convaincre.
                              Il y a des concepts qui s'exprime naturellement en objet et aussi en C. Le "FILE *" de la libc, c'est définitivement un object. Trouve ça horrible si tu veux (je trouve ça moche aussi à côté des facilités C++), mais c'est un object.

                              > Peu importe qu'il y ait des bindings.

                              Non. Et je ne comprend pas ce type argument qui flirt avec le ridicule. Le choix du C pour gtk c'est les bindings. Donc ne critiquez pas ce choix sans considérer les bindings, sans considéré les objectifs de gtk.

                              Si tu définis les objectifs de gtk alors oui gtk aurait dû peut-être être fait dans un autre language. Mais pourquoi on choisi un language ? Car on a des objectifs.
                              Il faut faire une interface pour une base de donnée, VB est un bon choix. Il faut faire une interface pour un automate avec des contraites temps réel, une interface très riches qui remonte beaucoup d'info, alors VB est un mauvais choix.

                              Ignorer les objectifs dans le choix d'un language est une aberration.

                              > le langage d'implementation par défaut conditionne le reste.

                              Tu l'as dit.

                              > On utilise UN langage et on permet aux applis clientes d'utiliser leur propres langages pour communiquer. C'est le minimum attendu et je vois pas en quoi Gtk serait plus une réussite à ce niveau que Qt ou les ports pour Gnustep.

                              Rires. Si C++ roxe des ours dans tous les domaines et même pour faire des bindings, pourquoi Qt en chie pour avoir des bindings ?
                              Tu m'expliques ça ?

                              Manque de popularité ?
                              Ça m'étonnerais, vois comme je me fais moinser pour "défendre" gtk.

                              KDE utilise plein de lib en C. KDE peut piocher dans les librairies C et si besoin faire un wrapper C++. KDE mais aussi python, perl, java, C#, ada, php, etc... L'inverse est rare. Tu m'expliques ça ?

                              Et ce n'est pas de la mauvaise fois de ma part ou du troll ou autres conneries dans ce goût dont on m'accuse, c'est un FAIT.

                              > Ce qu'on t'explique c'est qu'il faut utiliser le bon outil pour la bonne tâche.

                              Les faits montrent que gtk a utilisé le bon outil pour la tâche d'avoir des bindings.

                              > Si t'en es là pourquoi ne pas recoder le kernel entièrement en assembleur plutôt que certaines parties incoutournables.

                              ???
                              Il y a des objectifs, parfois le C est adapté, parfois le C++, parfois VB, parfois l'assembleur.
                              Mais pour les objectifs de gtk, le C++ n'est pas adapté.

                              > Mais pour le reste c'est à dire l'essentiel c'est implenté complétement avec un langage ... objet.

                              Pourquoi pas. Et gtk le permet.
                              • [^] # Re: Performances

                                Posté par . Évalué à 2.

                                Tu deviens un peu plus interessant quand tu arrêtes de troller.

                                Fort bien l'un des objectifs de Gtk est de fournir des bindings pour tous les langages de la création.
                                Seulement sa conception est basée sur l'objet.
                                Dès que tu l'utilises avec un langage qui se réfère à un autre paradigme tu es forcé de simuler celui de l'objet. Faire du fortran objet , quel intêret ?

                                Qt s'est fixé pour objectif de faire une lib bien conçue et ce qui permet d'entreprendre des changements de conception plus simplement. Les bindings vers les pricipaux langages existent aussi. Donc l'objectif est rempli également. Je ne vois pas en quoi Qt en chie comme tu dis .A la limite c'est sûr que pour des langages procéduraux la tâche est plus ardue. Rendre un hériatage multiple avec du C ne doit pas être évident par exemple.
                                Les bindings comme PyQt se focalisent sur le fait d'apporter des fonctionnalités supplémentaires propres au lanage hôte (comme par exemple etendre les signaux/slot en dynamique).


                                En passant, la POO n'est pas réservée à aux languages dédiés POO. Linux est un assez bon exemple de POO. Lis les sources pour t'en convaincre.
                                Il y a des concepts qui s'exprime naturellement en objet et aussi en C. Le "FILE *" de la libc, c'est définitivement un object. Trouve ça horrible si tu veux (je trouve ça moche aussi à côté des facilités C++), mais c'est un object.

                                sauf que le seul mécanisme que tu cites est l'encapsulation et encore de façon imparfaite. Ce n'est qu'un des concepts de la POO. dès que tu la fait intervenir avec l'héritage, le C montre ces limites. Les cast de structures ne résolvent pas tous les problèmes. Lorsqu'il s'agit d'encpasuler les opérations et d'hériter des comportements on se retrouve vite avec des pbs set on doit alors rajouter moulinettes dans tous les sens ou faire preuve de riguer au lieu de se reposer sur lel angage.
                                Ne parlons pas du polymorphisme. Avec du C et l'utilsation intensive du void* tu peux te retrouver assez facilement avec des core dumps. Chose qu'un langage objet est capable de gérer. (Compilation impossible avec un langage statique, Exception avec
                                Ne parlons pas du multi-héritage, de la façon de gérer les exceptions , ... )

                                Sinon si tu veux parler de KDE, compare le avec Gnome et son Mono/C# pas avec Gtk.
                                • [^] # Re: Performances

                                  Posté par . Évalué à 3.

                                  Vous êtes si bien partis que je suppose que ce ne sera pas le mot de la fin, mais je ne peux pas m'empêcher de citer Havoc :

                                  Why does Gnome use C for object-oriented programming?
                                  HavocPennington: It's just history. There isn't any big reason.

                                  Les bindings, les performances, c'étaient peut-être de bonnes raisons il y a 10 ans, mais plus vraiment maintenant. Je crois qu'il y a consensus sur ce sujet.
                                • [^] # Re: Performances

                                  Posté par . Évalué à 2.

                                  > Fort bien l'un des objectifs de Gtk est de fournir des bindings pour tous les langages de la création.
                                  > Seulement sa conception est basée sur l'objet.

                                  Et ?
                                  Je ne vois pas le problème. Dans Linux il y a plein d'objets aussi. En quoi passer à C++ rendrait Linux meilleur ?
                                  Pourtant Linus a voulu un certain temps passer à C++. Mais il a trouvé qu'il y avait des problèmes et a abandonné l'idée. Désolé, je ne connais pas les détails de l'affaire. Je les connais dans les grandes lignes mais l'expliquer ici serait long et hazardeux. Principalement des problèmes d'optimisation.

                                  Même si un langage n'est pas adapté à la POO, pourquoi s'interdir de faire de la POO ?
                                  Il y a ici quelque chose qui m'échate.
                                  Comme tu veux implémenter par exemple des menus sans faire de programmation object ou seulement en utilisant un paradigme procédural ?

                                  Voilà un menu :
                                  struct menu {
                                  bool sub_menu ;
                                  void* action_or_menu ;
                                  ...
                                  } ;
                                  struct menu main_menu[] = { true, menu_fichier}, {false, display_about}} ;


                                  Ok, c'est immonde, mais c'est d'idée qu'il faut suivre.
                                  C'est de la programmation objet et c'est très courant en C.

                                  > Dès que tu l'utilises avec un langage qui se réfère à un autre paradigme tu es forcé de simuler celui de l'objet.

                                  Ça dépend comment tu penses. L'exemple précédent ne simule pas de l'objet. C'est de l'objet. Si tu penses structures de données, pointeurs de fonction, il se peut que tu ne te rendes pas compte que c'est de l'objet.

                                  Si l'objet pour toi demande systématiquement de l'édition de lien dynamique, des type utilisateur, etc... alors pour faire de l'objet en C il faut le "simuler" et rentrer dans des techniques pas évidentes à mettre en oeuvre. Mais c'est ta conception de la POO, c'est ta façon d'aborder la programmation qui te fait penser que le C ne doit pas être utiliser pour faire de la POO.
                                  Je peux t'assurer qu'on peut être redoutablement efficace en C même en faisant de la POO. Par contre si tu veux tout le luxe de la POO en C, c'est beaucoup plus lourdingue de le faire. Notes que faire une librairie C++ avec tout le luxe de la POO, c'est aussi beaucoup de boulot (et même beaucoup plus qu'on ne le croit en général).

                                  Un autre exemple de programmation object très courrant, c'est tout ce qui est lié aux bases de données. Chaque enregistrement est une instance d'un object, ils ont des propriétés, par contre les méthode ne sont pas dans la base de donnée (ou rarement). Mais il y a souvent ici le paradigme POO d'appliqué.

                                  Dès que tu fais un système de plugins, tu fais de la programmation objet. Et si c'est en C, ce n'est pas un cauchemard à réaliser.

                                  > Qt s'est fixé pour objectif de faire une lib bien conçue

                                  Qt est une superbe librairie.

                                  > Les bindings vers les pricipaux langages existent aussi.

                                  Certe.

                                  > Je ne vois pas en quoi Qt en chie comme tu dis .

                                  Un exemple :
                                  http://developer.kde.org/language-bindings/java/ Pas vraiment complet. Et pourtant Java est object "comme" Qt.
                                  Java pour gtk (mais aussi gconf, gnome, gstreamer, etc) existe depuis un bon moment.

                                  > Donc l'objectif est rempli également.

                                  Tout est possible. Théoriquement je ne vois pas pourquoi il n'y aurait pas de binding pour Qt. Mais c'est lourd à mettre en oeuvre. D'autant plus si Qt veut utiliser toutes les fonctionnalités du C++.

                                  > Les cast de structures ne résolvent pas tous les problèmes. Lorsqu'il s'agit d'encpasuler les opérations et d'hériter des comportements on se retrouve vite avec des pbs set on doit alors rajouter moulinettes dans tous les sens ou faire preuve de riguer au lieu de se reposer sur lel angage.

                                  Ben oui. Et plus tu montes la barre haut en exigence de fonctionnalités, plus tu as des difficultés pour faire des bindings, plus tu es exigent envers le language à "binder", moins tu es neutre envers les language pourvant être bindé.
                                  • [^] # Re: Performances

                                    Posté par . Évalué à 2.

                                    J'ai déjà répondu à tes remarques un peu plus loin dans le thread.
                                    Mais en gros effectivement le langage C ne supporte de façon a peu près gérable qu'un sous-ensemble du paradigme objet.

                                    Oui, le choix du langage d'implémentation influe sur la conception
                                    Le choix de Gtk est d'offrir des possibilité limitées pour supporter un max de langages. Chaque langage et notamment tous les langages objets doivent donc réimplémenter certaines fonctionnalites pour arriver à un niveau de fonctionnalités qui sera finalement commun entre eux ou laisser le soin au developpeur d'application de refaire le travail à son niveau?
                                    Gtk fait le choix du plus petit commun dénominateur en ayant choisi le C

                                    Qt offre plus de possibilités mais contraint les langages plus limtés à mettre en oeuvre des contournements. Pour autant ce n'est pas chose impossible et certains bindings sont de belles réussites.

                                    Pour Java, ton lien date un peu puisque Trolltech propose maintenant son propre binding
                                    http://www.trolltech.com/developer/downloads/qt/qtjambi-tech(...)
                                    • [^] # Re: Performances

                                      Posté par . Évalué à 3.

                                      > Le choix de Gtk est d'offrir des possibilité limitées pour supporter un max de langages.

                                      Non. C'est comme si tu disais que Linux offrait des possibilités limités.
                                      Gtk demande peu au niveau fonctionnalité du language. Ça ne veut pas dire que c'est limité. Tous les programmes finissent en assembleur, ils ne sont pas forcément limités.
                                      Bien que gtk puisse se programme en C classique, il peut aussi se programme en avec du "pure" C++ ou Python, etc... On peut avoir des constructeurs, surcharge des opérateurs, dériver, etc... le mieux adapté au language (il y a évidement quelques cas particuliers).

                                      > Gtk fait le choix du plus petit commun dénominateur en ayant choisi le C

                                      Pas au niveau fonctionnalité. La façon donc sa va être implémenté pour les autres languages, dépend des autres languages et de la façon dont c'est implémenté (pléonasme). Si c'est du java, c'est du java 100 % (disons 95%), ce n'est pas java limité au C.

                                      > Qt offre plus de possibilités

                                      Tu (et je aussi peut-être) mélange facilité du language et possibilité/fonctionnalité de la librairie.
                                      Une librairie avec des possibilités limités, qu'elle soit en C++ ou C reste une librairie limité.

                                      Gtk gère les thèmes car on veut que toutes les applis soient "unifiées". Gtk offre une boite "save as" complète et utilise gnome-vfs s'il est là, car on veut que toutes les applis utilisent la même boite. Gtk gère le position des widgets les un par rapport aux autres (élastique), etc...

                                      Il ne sagit pas de limité les fonctionnalités, mais de les mettres à leur place.

                                      Si chaque language recode la boite "save as" ou les thèmes, c'est une perte de temps et une perte de cohérence de l'ensemble du bureau.

                                      Certe aujourd'hui une appli swing ou eclipse ne ressemble pas parfaitement à gtk, mais ce n'est pas une feature, c'est un défaut qui doit être corrigé (c'est mon avis) comme il est corrigé petit à petit dans OOo, Firefox, etc. Pas car gtk roxe, mais pour avoir un bureau cohérent.
                                    • [^] # Re: Performances

                                      Posté par . Évalué à 2.

                                      > Gtk fait le choix du plus petit commun dénominateur en ayant choisi le C

                                      Alors là c'est faut. C/GObject permet les constructeurs de classes, les destructeurs d'instance/de classe, introspection, etc.

                                      C/GObject est au contraire plutôt complet.

                                      Étienne.
                                      • [^] # Re: Performances

                                        Posté par . Évalué à 1.

                                        Ce qui ne contredit pas la phrase que tu cites
                                • [^] # Re: Performances

                                  Posté par (page perso) . Évalué à 2.

                                  Programmation objet et C... un peu de lecture

                                  http://ldeniau.web.cern.ch/ldeniau/html/oopc.html

                                  Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

                              • [^] # Re: Performances

                                Posté par . Évalué à 2.

                                Ah et j'oubliais:

                                C'est Kernighan qui disait que tout bon programme C est orienté object. Du montant que tu as des structures et que tu y associés des fonctions (de façon directe ou non avec les pointeurs de fonction, en utilisant des types, etc) c'est de la programmation object. Ou dit que c'est de l'encapsulation de données si ça vexe ta haute idée de la POO.

                                Merci de citer ce cher Kernighan pour convenir qu'une bonne conception est objet et qu'il vaut donc mieux utiliser un langage objet plutôt que procédural pour arriver au même résultat. D'où ma petite remarque un peu plus haut sur le marteau et la vis.
                                Notes que la POO ne résoud pas tous les pbs, ce qui explique la venue de concepts transversaux comme l'AOP par exemple.
                                Sinon quand je parle de contre-productivité c'est bien de ca qu'il s'agit .

                                Avec une telle conception tu dois impléménter l'héritage virtuel en écrasant toi même ton pointeur de fonction dans l'instanciation de ton objet ou mettre en place un mécanisme d'indirection à la place du compilo.
                                Si tu veux faire persister des objets dans des fichiers à plat (comme des paramètres de config de ton appli), tu dois concevoir ton application afin de ne stocker que les données et pas les blocs alloués à tes pointeurs d'opération. Sinon tu devras faire un programme de reprise de données pour réaligner les blocs en récompense de ta négligence. Heureusement les petits gars de GTk font une bonne partie du boulot pour nous (j'imagine) qui utilisons ces supers bindings alors qu'ils auraient pu réflechir à plein d'autres trucs intéressants.
                                Avec une telle conception tu dois passer ton temps a caster ton objet dans ton code pour tes appels polymorphes à une référence de cet objet alors que ton compilo C++ le déduit tout seul. Si tu es feignant tu mets des void* partout dans les signatures de tes contrats et il y aura toujours un benet qui travaille sur une autre lib qui passera une mauvaise référence et qui fait planter son programme. Belle séance de debbugging en perspective....
                                Après avoir donné 5 ans dans le registre je peux te donner plein d'autres exemples.

                                Oui mais chez nous on a plein de bindings pour tous les langages de la création même le pour logo et en plus le C ca déchire question perf, Na!
                                • [^] # Re: Performances

                                  Posté par . Évalué à 4.

                                  D'où ma petite remarque un peu plus haut sur le marteau et la vis.

                                  Moi ce que j'aime bien avec les analogies c'est qu'avec un peu d'imagination on leur fait toujours dire ce que l'on veut...

                                  Donc la vis représente la POO, le marteau représente le C, un langage procédural. Oui, mais GObject lui, est la cheville que l'on a adapté à la vis afin d'obtenir une magnifique cheville à clouer (qui est reconnue pour sa rapidité de mise en ½uvre) nous permettant de faire de la POO avec du C.

                                  CQFD.
  • # Pas grand chose de neuf ...

    Posté par . Évalué à 3.

    Il n'y a même pas besoin de définir Vala comme un langage accepté dans Gnome, puisque c'est du C !


    Et si je fais un compilateur de python vers C, qu'on appellerait pyc, avec un système de bindings pour utiliser des bibliothèques C, il n'y aurait pas besoin de définir le python comme un langage accepté dans gnome, puisque "c'est du C ?"


    Plus sérieusement, des compilateurs pour traduire d'un langage quelquoque vers du C, il en existe pleins, ça n'a pas grand chose d'extraordinaire. Tu as l'air de confondre le lagage en lui même et ses implémentations potentielles ... pour moi vala ça ressemble à une défaite des principes qui sous-entendent l'utilisation du C par gnome: on utilise du C parce que performant et pour faire des bibliothèques, mais au final c'est trop chiant alors on fait comme les autres et on passe à un truc plus haut niveau :)

    Pour les perfs, ça dépends autant de l'implémentation du langage que du langage lui même.

    Le seul intéret que j'y vois par rapport à l'utilisation d'un autre langage de plus haut niveau est de réutiliser l'existant. Après, pourquoi avoir réécris un nouveau langage et pas avoir réécris un compilateur C# par exemple (je dis ça parce que le lagage dit s'en inspirer) ?
    • [^] # Re: Pas grand chose de neuf ...

      Posté par . Évalué à 4.

      L'avantage de Vala, c'est qu'il est conçu pour GObject, contrairement à python et C# pour reprendre tes citations.

      > pour moi vala ça ressemble à une défaite des principes qui sous-entendent l'utilisation du C par gnome

      Vala est loin d'être le futur langage de Gnome. Ça fait belle lurette que Gnome n'est pas écrit totalement en C/GObject. C++, Java, C#, perl et Python ont leur passerelles dans Gnome ( http://live.gnome.org/TwoPointNineteen/Bindings ). Le GObject a été conçu avec deux objectifs :

      * avoir une API object en C
      * passerelle automatique et transparente pour d'autre langages compilés où interprêté.

      ( cf. http://developer.gnome.org/doc/API/2.0/gobject/chapter-intro(...) ).

      Dans le concept même de GObject, il n'y a pas l'exclusivité du C/GObject. Gnome se veut agréable pour l'utilisateur mais aussi le développeur en lui laissant le choix du langage (autant que possible). Vala n'est et ne sera qu'un choix de plus dans la liste !

      Étienne.
      • [^] # Re: Pas grand chose de neuf ...

        Posté par . Évalué à 2.

        Certe, mais C/GObject n'a aucun intérêt en soi dans d'autres langages qui proposent leur propre modèle objet.

        C'est assez curieux comme démarche je trouve d'implémenter un modèle objet dans un langage non objet, et ensuite seulement d'inventer le langage qui va avec le modèle. C'est comme si tu avais commencé à implémenter un langage objet en C sans même connaître le langage ...

        Ça fait aussi furieusement penser aux concepts de .NET, avec sa machine virtuelle conçue pour implémenter des langages objets entre autre, sauf qu'ici on compile en C/Gobject et pas dans le langage de la machine virtuelle ( CLR ? )
        • [^] # Re: Pas grand chose de neuf ...

          Posté par . Évalué à 2.

          Certe, mais C/GObject n'a aucun intérêt en soi dans d'autres langages qui proposent leur propre modèle objet.


          Ben justement l'intérêt c'est de pouvoir transposer cette architecture en "objets" facilement dans un language qui propose directement ces facilitées. Les bindings n'ont pas à définir un arbre d'héritage: il existe déja ! Aussi pour la documentation, l'API du binding et la documentation officielle de GTK suffisent.

          Si on ne veut pas faire de GObject, on utilise un binding dans le language de sont choix et c'est tout. point barre.
  • # Commentaire non constructif...

    Posté par . Évalué à 2.

    ... mais je peux pas résister après avoir lu ça :
    Une recherche sur linuxfr pour le terme "vala" met bien en valeur la pauvreté de l'orthographe des linuxèfèriens. En effet c'est à chaque fois une orthographe douteuse du mot "voilà" qui est recensé.
    et puis ça :
    Concrètement, Vala traduit un synthaxe proche du C# directement en C/GObject.


    Pour faire à moitié semblant d'apporter quelque chose à un semblant de débat : je suis contre le langage SMS, les fautes d'orthographe à outrance (quand elles sont faites par quelqu'un qui pourrait les éviter en prenant la peine de se relire), et pourtant j'aime bien des expressions du style maichant, saymal, flashcaymalsapusaypalibre, etc. Contradiction ?

    (Attention un deuxième troll s'est glissé dans ce message)
  • # Debugger ?

    Posté par (page perso) . Évalué à 2.

    Et comment est ce qu'on débugge un programme vala ?
    L'idée, c'est bien :
    machin.vala -- valac -> machin.c -- gcc -> executable
    donc j'imagine qu'on ne peut débugger que le fichier c généré ou alors y a moyen de remonter aux sources vala.

    En tout cas, c'est un projet intéressant, permettant de remplir à la fois l'objectif de gnome d'écrire toute sa lib en C pour être portable et le désir de certains progammeurs d'utiliser un langage de haut niveau.
    En tout cas, je trouve que c'est une bonne idée, je m'interroge juste sur les possibilités de debuggage.
    • [^] # Re: Debugger ?

      Posté par . Évalué à 2.

      Salut,

      À mon avis, ça doit se debogué comme du pygtk. Sauf si on tombe sur une bogue de vala. C'est clair cependant, que savoir ce qui se passe sous le capot n'est pas inutils, comme partout … Faudrait voir ça en détail avec les dévs de Vala.

      Étienne.
      • [^] # Re: Debugger ?

        Posté par . Évalué à 7.

        De toute façon, les debogueurs, c'est pour les mauvais programmeurs, ceux qui laissent des bogues. Pour les autres, c'est inutile.
    • [^] # Re: Debugger ?

      Posté par . Évalué à 5.

      De la même manière qu'on débug un programme utilisant Yacc, je pense. Pour ceux qui ne connaissent pas, Yacc est un "langage" qui décrit un parseur de langages. On écrit le parser en Yacc, et il est traduit en C, puis intégré dans le programme final.

      Il y a des instructions qui indiquent au compilateur C la correspondance entre sa ligne de code C et la ligne de code Yacc correspondante. Du coup, les informations de débuggage renvoient vers la bonne ligne.
    • [^] # Re: Debugger ?

      Posté par . Évalué à 3.

      C'est dans leur roadmap :
      Add line pragmas to locate which vala code leads so C error messages and warnings (code is prepared).


      http://live.gnome.org/Vala/Roadmap

Suivre le flux des commentaires

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