Journal Quelques nouvelles de LaTeXila, et réflexions sur le développement d'IDE en GTK

Posté par  .
Étiquettes :
16
25
avr.
2010
Bonjour,

Ça fait un petit temps que je ne vous ai plus parlé de LaTeXila, un IDE LaTeX en GTK que j'ai commencé l'été passé, avec pour objectif d'avoir une alternative à Kile qui lui est en Qt.

Il faut tout d'abord remercier farvardin pour la réalisation du logo, de l'icône de l'application (qui reste cependant à améliorer) et le design du site (que j'ai amélioré), suite à ma demande dans le journal précédent.

Version 0.2

LaTeXila en est à sa version 0.2 (sortie en février), dont le principal changement par rapport à la version 0.1 est le filtrage des messages affichés lors de la compilation. Quiconque ayant déjà compilé un fichier LaTeX en console sait de quoi je parle ;) Donc j'ai lu le code source de Kile pour ne pas réinventer la roue, en réglant quelques imperfections (Kile les a corrigé aussi après un rapport de bug).
Donc maintenant seulement les erreurs, warnings et badboxes (par exemple quand le texte dépasse d'une marge) et autres messages d'informations (comme la taille du fichier généré) sont affichés, avec des couleurs, etc. On peut cliquer dessus pour aller directement dans le fichier et la ligne concernés.

La suite : repartir sur des bases saines, le tout en Vala
Bien que l'application soit tout à fait fonctionnelle et que je n'ai découvert aucun bug dans la dernière version stable, je compte repartir de zéro.

Il y a plusieurs raisons à cela :
  • LaTeXila est ma première application en GTK+, quand j'ai commencé je ne connaissais rien de cette bibliothèque. J'ai décidé assez naturellement de le faire en C, puisque GTK+ est lui-même écrit en C, que j'aime bien ce langage, que les performances sont excellentes, etc. La structure actuelle du code convenait assez bien pour une petite application de quelques milliers de lignes. Mais plus je rajoutais des fonctionnalités, plus le code devenait de moins en moins beau et maintenable. Pour le long terme c'est tout simplement une très mauvaise idée de continuer dans cette direction, me semble-t-il.

  • Comme nouvelle structure de code, je compte m'inspirer de Gedit, c'est à dire entièrement en orienté objet en créant ses propres widgets (soit dérivés d'autres, soit « from scratch »). Tout ça grâce à la puissance de la bibliothèque GObject, qui est la base de la GLib, GTK, et toute autre bibliothèque de GNOME.

  • Le langage Vala simplifie énormément la création de ses propres widgets/classes basés sur GObject. C'est entièrement intégré dans la syntaxe du langage (qui est proche du C# et de Java) ! Tandis qu'en C ça demande beaucoup plus de boulot. Comme Vala est de plus haut niveau que le C, on est aussi plus productif, notamment pour ce qui est de la gestion de la mémoire. En plus les performances sont très bonnes, puisque le code source Vala est d'abord traduit en C et ensuite compilé avec GCC.

  • La nouvelle structure du code serait la même en C ou en Vala, puisque c'est de l'orienté objet et que ce serait tous les deux basés sur GObject. Ce qui me fait donc pencher pour Vala. Même si ce sera mon premier projet en Vala, la structure du code sera bonne (enfin, j'espère), donc si il y a des imperfections au début il ne faudra pas tout recommencer à nouveau par la suite.

  • Tout ne sera pas forcément perdu, et ça ira beaucoup plus vite que la première fois.

Pourquoi ne pas améliorer le plugin LaTeX de Gedit ou créer un autre plugin ?

L'avantage d'un éditeur indépendant c'est qu'on a aucune limitation, et donc au final on a quelque chose de plus cohérent. On a plutôt l'impression que ça forme un « tout » et pas une base sur laquelle on est venu greffer des morceaux.

Pour comparaison, il aurait été difficile à mon avis pour Kile de faire quelque chose d'aussi bien avec un simple plugin pour l'éditeur de texte de KDE (Kate).

Et les plugins de Gedit, c'est assez difficile à gérer lorsqu'on doit faire plusieurs tâche en même temps (par exemple écrire un rapport en LaTeX pour un projet fait avec le langage Oz pour lequel un autre plugin est nécessaire). En gros, ça peut vite devenir une usine à gaz. Mais il y a une solution à ça, qui se trouve dans les fonctionnalités demandées (§ 1) : les profils.

Gedit, LaTeXila et d'autres IDE écrits en GTK+ utilisent la bibliothèque GtkSourceView. Donc pas mal de fonctionnalités ne sont pas dupliquées. Cependant la situation est meilleure du côté de KDE.

Les éditeurs de texte et IDE écrits en Qt utilisent l'API KTextEditor, implémentée par Kate Part. On peut voir que cet API est de plus haut niveau que GtkSourceView, notamment pour la gestion de documents (créer des nouveaux documents, avoir une liste de documents ouverts, etc).

Donc, il y a quand même un certain nombre de fonctionnalités implémentées dans Gedit et qui sont en quelque sorte dupliquées dans LaTeXila.

Mais si GtkSourveView s'améliore et devient de plus haut niveau pour éviter la duplication de code, alors il n'y a plus aucun problème.

Ou bien développer une autre bibliothèque qui comble les lacunes de GtkSourceView et qui s'appellerait par exemple GtkSourceEdit. Et cette nouvelle bibliothèque pourrait même être écrite en Vala, puisque ce serait compatible avec les autres applications écrites en C.

Bref il y a là de la matière à réflexion !

La numérotation des versions

Les versions se sont enchainées comme suit : 0.0.1 -> 0.0.2 -> 0.1 -> 0.2.
Dans l'optique d'arriver à la 1.0 quand toutes les fonctionnalités importantes sont intégrées.

Un problème se pose maintenant, puisqu'il y aura une grande restructuration du code et un changement de langage... MAIS que l'interface utilisateur ne sera que peu modifiée. Que faire ? Rester sur la numérotation actuelle et sortir une version 0.3 ? À ce moment-là il faut absolument que cette version garde toutes les fonctionnalités de la 0.2 et éventuellement en rajouter.

Ou bien — ce qui est plus logique lorsqu'un projet restructure entièrement son code — incrémenter la version majeure, donc passer de 0.X à 1.X. Un peu comme KDE 4.X, Gnome 3.X, etc. Mais ça ferait bizarre je trouve de sortir une version 1.0 après la 0.2 alors que le code a complètement changé et qu'il manque peut-être des fonctionnalités par rapport à la version précédente.

Donc je pense que je vais opter pour la 2.0, et numéroter à la Gnome, c'est à dire les versions stables seront : 2.0 -> 2.2 -> 2.4 -> ... Et les versions instables : 1.99 -> 2.1 -> 2.3 -> ...

Conclusion

Avant de foncer tête baissée, je compte bien réfléchir si l'idée que j'ai pour l'instant est la meilleure. De toute façon je n'ai plus beaucoup de temps libre jusqu'à la mi-juin, où là je compte réellement m'y mettre. En attendant je vais bien sûr apprendre et pratiquer un peu le Vala, essayer de discuter avec les devs de GtkSourceView et éventuellement ceux de Gedit. J'ai envoyé un message sur la ML (gtk-list) mais aucune réponse pour l'instant... Peut-être réessayer sur une autre ML, sur IRC ou même rencontrer les devs au GUADEC à La Haye (mais je préfère les mails vu que je suis pas encore vraiment à l'aise en anglais).

En tout cas je suis motivé pour qu'un bon IDE LaTeX en GTK existe, donc soumettez-moi vos idées :) Et je suis toujours ouvert à toute contribution ou collaboration.
  • # Fonce!

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

    Je crois que tu es sur la bonne voie: tu as l'air d'avoir bien étudié le problème et les solutions existantes, et tes choix technologiques me semblent pertinents.

    Attention par contre de ne pas t'épuiser: il faudra du temps avant d'arriver à égaler ce que tu as fait avec la version existante.

    Petite question: où le développement a-t-il lieu? Si tu mets le code sur github ou équivalent, ça ne m'étonnerait pas que tu trouves quelques contributeurs, au moins occasionnels. Et pourquoi pas moi, la prochaine fois que j'aurai a écrire un gros truc en LaTeX :)
    • [^] # Re: Fonce!

      Posté par  . Évalué à 9.

      >>> tes choix technologiques me semblent pertinents.

      Je pense qu'il aurait dû utiliser le couple Qt/C++ :)
      • [^] # Re: Fonce!

        Posté par  . Évalué à 3.

        Un like-kile en Qt ? euh non klie-like, raah kile-like, je vais y arriver.*
        Ben ça existe déjà : TexMaker (multiplateforme lui).

        * quoi ça se voit que je fais exprès ? -->[]
        • [^] # Re: Fonce!

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

          Notez que Kile est à l'origine un fork de TeXMaker.
          • [^] # Re: Fonce!

            Posté par  . Évalué à 9.

            Kile nest pas un fork de Texmaker car il l'a précédé.
            J'ai créé et maintenu Kile jusqu'à la version 1.5.2 et c'est ensuite que j'ai créé Texmaker.

            P.Brachet
    • [^] # Re: Fonce!

      Posté par  . Évalué à 2.

      Pour l'instant le code est sur SourceForge, avec Git comme gestionnaire de versions.
      Mais je compte peut-être migrer sur GitHub, qui a l'air plus rapide et meilleur pour gérer un projet avec Git (et qui ne censure pas certains pays ;).

      La version 0.2 fait en effet 10 000 lignes de code, donc c'est clair que la « migration » ne se fera pas un jour. Mais j'aurai presque toutes les grandes vacances (3 mois) de libre, si j'ai pas de seconde sess'. Donc j'espère arriver à un assez bon résultat en aout, pour ajouter en septembre une grosse fonctionnalité manquante : la complétion automatique. C'est un peu comme un GSoC sans mentor (il y a toujours les forums et ML de toute façon), sans être payé mais avec moins de pression ;)
      • [^] # Re: Fonce!

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

        Ou sinon, tu le prends chez toi, le dépôt Git. Ce n'est pas compliqué à mettre en placE.
        • [^] # Re: Fonce!

          Posté par  . Évalué à 2.

          Il faut à ce moment-là une machine connectée en permanence à internet, ce que je n'ai pas. Donc même si c'est moins flexible, je préfère SF ou GitHub, là je suis presque sur que n'importe qui peut prendre la version en développement n'importe quand.
          Et il y a aussi l'hébergement du site web qui est fourni aveC.
          • [^] # Re: Fonce!

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

            Ou gitorious, dont l'interface est libre, contrairement à github.
            • [^] # Re: Fonce!

              Posté par  . Évalué à 3.

              Ça a l'air très intéressant, notamment en voyant des grands noms comme Qt, OpenSuse, FreeBSD, Webkit ou Blender qui l'utilisent !
              Je vais comparer les différentes offres et privilégier Gitorious si c'est plus ou moins équivalent.

              Un truc que j'aimerais garder en migrant de SF vers autre chose c'est garder le site web avec la feuille de style. Tout ce que j'ai vu sur GitHub ou Gitorious c'est un wiki... Et je ne demande même pas de PHP ou Python avec base de données ou autres, c'est une bête page statique.
              • [^] # Re: Fonce!

                Posté par  . Évalué à 4.

                Un truc que j'aimerais garder en migrant de SF vers autre chose c'est garder le site web avec la feuille de style. Tout ce que j'ai vu sur GitHub ou Gitorious c'est un wiki... Et je ne demande même pas de PHP ou Python avec base de données ou autres, c'est une bête page statique.

                c'est possible chez github: http://pages.github.com/
              • [^] # Re: Fonce!

                Posté par  . Évalué à 2.

                Tu peut aussi regarder cette forge (indefero) :
                http://linuxfr.org/2010/04/19/26753.html

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Fonce!

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

                Que pensez-vous de launchpad? Je ne connais pas très bien, mais je suis tombé par hasard hier sur un projet qui l'utilise, et ça a l'air très sympa.
  • # Note aux modos

    Posté par  . Évalué à 10.

    Journal intéressant et bien écrit à convertir en dépêche :)
    • [^] # Re: Note aux modos

      Posté par  . Évalué à 2.

      Il faudrait dans ce cas-là rajouter une liste des fonctionnalités les plus importantes (voir journal précédent ou sur le site), la licence (GPL 3+), le gestionnaire de version (Git), le générateur de Makefile (CMake), disponibilité d'un RPM pour Fedora et disponible dans AUR pour ArchLinux et un lien vers une capture d'écran.

      Mais si j'avais décidé d'écrire directement une dépêche j'aurais sans doute formulé mes phrases autrement, moins parler en « je » par exemple.
      • [^] # Re: Note aux modos

        Posté par  . Évalué à 2.

        Ah oui, et aussi peut-être expliquer un peu l'algorithme utilisé pour le filtrage et l'extraction des données de la compilation, qui est en fait une heuristique (donc c'est pas parfait).

        D'où aussi une autre idée de projet qui consisterait à améliorer pdfTeX en rajoutant deux options : --output-user-friendly et --output-machine-friendly. La première pour ceux qui compilent en console, et l'autre pour faciliter l'extraction de données par les IDE.

        Mais en faisant un grep de certaines chaines de caractères contenues dans la compilation pour voir où se trouvait le code source concerné, je suis tombé sur un truc que j'avais jamais vu : un fichier pdftex.web de 39000 lignes de code dont le développement a débuté en 1977. Le langage WEB est un langage de plus haut niveau que le Pascal, traduit d'abord en Pascal et puis compilé (tiens ça me fait penser à quelque chose...). Pour plus d'info rendez-vous à la ligne 180 de ce fichier (src/texk/web2c/pdftexdir/pdftex.web).

        Bref j'ai vite abandonné l'idée... Mais faudrait que je soumette une feature request.
        • [^] # Re: Note aux modos

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

          TeX est effectivement écrit en WEB, un langage adapté à la programmation lettrée. Il était à l'origine traduit en Pascal, mais aujourd'hui on en fait du C, avec Web2C.
        • [^] # Re: Note aux modos

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

          Pourquoi "qui est en fait une heuristique (donc c'est pas parfait)" ?

          Une heuristique c'est un moyen pour arriver à un résultat plus rapidement. Même si souvent les heuristiques permettent de donner une approximation d'un résultat, ce n'est pas forcément le cas. Mais ça l'est peut être ici ?

          Je n'ai donc pas compris ce "donc" dans ta phrase. Une erreur ou c'est moi qui ai mal compris ? En tout cas il me semblait bon d'en parler parce qu'il n'y a jusqu'à pas si longtemps de cela, pour moi une heuristique était forcément une approximation. Cela faisait par exemple que je pensais bêtement qu'un A* était forcément approximatif et qu'il était préférable d'utiliser un Dijkstra si on voulait un résultat juste. (je cite cet exemple parce que c'est lorsque j'ai entendu parler d'«heuristique admissible» que j'ai compris)
          • [^] # Re: Note aux modos

            Posté par  . Évalué à 1.

            Oui, une heuristique est une approximation, donc ce n'est pas un algorithme qui donne à chaque fois le résultat le plus optimisé. Donc c'est pas parfait, mais ça peut l'être quand même (et c'est généralement le cas ici). Je ne vois pas ce qui cloche en disant ça...

            Dans ce cas-ci, c'est la détection au fur et à mesure de la compilation du fichier dans lequel on se trouve qui pose parfois quelques problèmes, comme expliqué dans le code source de Kile (et copié dans LaTeXila) :

            // There are basically two ways to detect the current file TeX is processing:
            // 1) Use \Input (srctex or srcltx package) and \include exclusively. This will
            // cause (La)TeX to print the line ":<+ filename" in the log file when opening a file,
            // ":<-" when closing a file. Filenames pushed on the stack in this mode are marked
            // as reliable.
            //
            // 2) Since people will probably also use the \input command, we also have to be
            // to detect the old-fashioned way. TeX prints '(filename' when opening a file and a ')'
            // when closing one. It is impossible to detect this with 100% certainty (TeX prints many messages
            // and even text (a context) from the TeX source file, there could be unbalanced parentheses),
            // so we use a heuristic algorithm. In heuristic mode a ')' will only be considered as a signal that
            // TeX is closing a file if the top of the stack is not marked as "reliable".
            • [^] # Re: Note aux modos

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

              "Oui, une heuristique est une approximation"

              => Je dis justement le contraire : Une heuristique n'est pas toujours une approximation.
              • [^] # Re: Note aux modos

                Posté par  . Évalué à 2.

                Ah ok je comprends mieux. Je ne comprenais pas où tu voulais en venir. Donc une heuristique admissible donne en fait à chaque fois le résultat optimal, et non une approximation. Mais c'est plutôt un cas particulier, et je ne sais pas si ça se présente souvent...
                • [^] # Re: Note aux modos

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

                  Bah disons que dans le cas du A* (j'utilise cet exemple mais ça doit être le cas pour d'autres choses), une heuristique admissible consiste à évaluer les sommets dans l'ordre tel que la distance entre le sommet évalué et le sommet final soit le plus petit en supposant qu'il puisse exister un chemin très court partant de ce sommet (en tenant compte du chemin déjà parcouru pour arriver à ce sommet bien sûr).

                  Par exemple sur une carte routière, si on cherche le chemin le plus court, il faut évaluer les sommets en se disant qu'il peut exister une autoroute qui suit le "vol d'oiseau" qui part de ce point. De ce fait on va évaluer en priorité les sommets les plus proches de la destination en priorité mais sans écarter les sommets qui sont derrières dans le cas où il y aurait un cas plus favorable. Le premier chemin trouvé est forcément le plus court.
                  (bien sûr, je simplifie mais c'est pour rester simple)

                  Mon intervention est un peu hors sujet et visait simplement à tordre cette idée reçue que heuristique implique approximation. J'étais tellement dans cette vision avant que j'avais eu du mal à voir comment faire pour que mon A* me sorte un résultat optimal. D'ailleurs suffit de lire wikipédia pour se rendre compte que c'est pas très clair : "L'algorithme A* a été créé pour que la première solution trouvée soit l'une des meilleures, c'est pourquoi il est célèbre dans des applications comme les jeux vidéo privilégiant le temps de calcul à l'exactitude des résultats."

                  On peut coder le A* simplement comme un Dijkstra dans lequel on ajoute une heuristique permettant d'évaluer les sommets dans un ordre plus efficace.


                  Je pense que si on mélange heuristique et approximation c'est sans doute parce que les heuristiques sont très utiles dans les problèmes compliqués où le résultat n'est pas garanti comme étant optimal. (cf algorithme glouton, metaheuristique, ...).

                  Bon et là, histoire d'illustrer un peu mon propos je faisais un tour sur wikipédia et je lis le contraire de ce que je viens d'expliquer : "Une heuristique, ou méthode approximative, est donc le contraire d'un algorithme exact qui trouve une solution optimale pour un problème donné."
                  D'un autre côté, on lit aussi des choses sur wikipédia qui vont dans mon sens...

                  Donc restez critique sur ce que vous lisez comme d'habitude. Je ne suis pas expert dans ce domaine après tout... Mais c'est ce que mon prof d'algo m'avait expliqué.

                  Je ne sais pas ce qu'on peut appeler "heuristique" et ça va dépendre de cette définition si cela se présente souvent ou non. J'ai lu qu'une heuristique était une méthode permettant de trouver une solution plus rapidement (exemple : faire un dessin pour mieux comprendre le problème qu'on essaye de résoudre) et donc dans ce cas, on peut arriver à prouver assez souvent que notre résultat est optimal.
                  • [^] # Re: Note aux modos

                    Posté par  . Évalué à 4.

                    En fait une heuristique en général, c'est tout moyen qui permet d'obtenir une solution meilleure qu'une solution aléatoire. Dans le cas de la recherche de plus court chemin par exemple, tu vas te dire que c'est plus malin de chercher un chemin dans la bonne direction que dans la direction opposée au point que tu veux atteindre.

                    Une "méthode heuristique" c'est souvent un synonyme de méthode incomplète : méthode qui ne garantit pas de trouver la solution, ou la solution optimale, mais qui on espère devrait trouver une bonne solution.

                    Dans le cas d'une méthode complète, typiquement l'heuristique a pour but de diminuer le temps de calcul dans les cas qui nous intéresse en faisant des meilleurs choix en différents points de l'algorithme, ou de trouver des bonnes solutions admissibles initiales pour amorcer l'algorithme, dans le cas de l'optimisation.

                    Et puis t'as les métaheuristiques, qui sont des méthodes souvent incomplètes qui sont génériques : on peut les adapter pour n'importe quel problèmes d'optimisation combinatoires, entre autres, et qui utilisent des opérateurs qu'on pourrait qualifier d'heuristiques, croisement, mutation pour les algos génétiques par exemple.
  • # Mouais, LyX comparé à ce genre de solution...

    Posté par  . Évalué à 1.

    J'ai utilisé Kile pas mal de temps, jusqu'à découvrir LyX. J'ai tout lâché, et j'ai même réussi à convertir mes profs de l'utiliser (victoire !). Chose impossible sur un truc comme Kile.

    Donc, je me pose une question pratico-pratique : ce genre d'outils apporte quoi comparé à un éditeur WYSIWYM (What You See Is What You Mean) que LyX représente ?
    • [^] # Re: Mouais, LyX comparé à ce genre de solution...

      Posté par  . Évalué à 4.

      Faire du LaTeX permet justement de se concentrer non pas sur la présentation du document mais sur son contenu et sa structure.

      Le visionnage en temps réel n'est que rarement utile selon moi. Et l'export en PDF ou autre format ne doit pas se faire toutes les 30 secondes non plus quand on maitrise le LaTeX. Évidemment quand on essaye de faire quelque chose hors des sentiers battus, là c'est nécessaire et c'est plus pratique avec un affichage en temps (presque) réel. Où à la finalisation du document où on arrive pas à placer les figures et tableaux là où on veut.
      • [^] # Re: Mouais, LyX comparé à ce genre de solution...

        Posté par  . Évalué à 0.

        >>> Faire du LaTeX permet justement de se concentrer non pas sur la présentation du document mais sur son contenu et sa structure.

        C'est partiellement faux, LaTeX mélange justement fond et forme : un exemple \textcolor{couleur}{texte à colorier} permet d'affecter la couleur ; Ce qu'apporte LaTeX, c'est le fait qu'un élément XXX aura le même aspect qu'un autre élément XXX, c'est tout.

        DocBook ou XLST sont des meilleurs pistes même si ce n'est pas l'idéal. Mais avoir un format qui sépare le fond de la forme, c'est pas encore gagné.
      • [^] # Re: Mouais, LyX comparé à ce genre de solution...

        Posté par  . Évalué à 1.

        Je me permet de signaler que LyX procède de même, c'est la complexité du balisage et la nécessité de le taper qui disparaît - et non pas la priorité du contenu sur la présentation.

        Lyx c'est bien, j'aime bien taper mon texte au kilomètre sans avoir à me rappeler la syntaxe latex tout en ayant les avantages.
        • [^] # Re: Mouais, LyX comparé à ce genre de solution...

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

          TeXMaker, Kile ou LaTeXila c'est bien, j'aime bien taper mon texte au kilomètre sans avoir à me rappeler la syntaxe LaTeX – quand je ne me souviens plus comment mettr eun titre de section, je clique pour le faire – tout en ayant ses avantage, en la voyant – le clic en question m'insère un \section{} – et en l'apprenant par la même occasion.
    • [^] # Re: Mouais, LyX comparé à ce genre de solution...

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

      Par rapport à LyX ? Une vraie maîtrise du code, je pense. C'est comme entre Dreamweaver et Vim ou Emacs, pour faire du HTML.
  • # Nous mes rotations

    Posté par  . Évalué à 10.

    Rester sur la numérotation actuelle et sortir une version 0.3 ? À ce moment-là il faut absolument que cette version garde toutes les fonctionnalités de la 0.2 et éventuellement en rajouter.

    Si tu n'as pas le temps de recoder toutes les fonctionnalités, le mieux est de passer en 4.0.
  • # Genie

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

    >>> Le langage Vala simplifie énormément la création de ses propres widgets/classes basés sur GObject.

    Est-ce que tu a choisi Vala après avoir évalué Genie ou pas ?
    • [^] # Re: Genie

      Posté par  . Évalué à 3.

      J'aime bien la syntaxe de Vala, surtout pcq je suis habitué au C et au Java. Mais la syntaxe de Python ne me dérange pas non plus, mais là Genie (qui est un mélange de Python, Boo, D et Delphi) ne m'attire pas.

      En plus, Vala est bien plus documenté, il y a plein d'exemples de code en GTK par exemple. Et je pense que Vala est plus répandu que Genie, donc je peux lire le code source de logiciels comme Val(a)IDE, qui est un IDE écrit en Vala, pour Vala (donc ça peut être intéressant de s'inspirer de ce logiciel, en plus de Gedit).

Suivre le flux des commentaires

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