Ç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 JoeltheLion (site web personnel) . Évalué à 5.
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 grid . Évalué à 9.
Je pense qu'il aurait dû utiliser le couple Qt/C++ :)
[^] # Re: Fonce!
Posté par Sébastien Wilmet . Évalué à 3.
Ben ça existe déjà : TexMaker (multiplateforme lui).
* quoi ça se voit que je fais exprès ? -->[]
[^] # Re: Fonce!
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -2.
[^] # Re: Fonce!
Posté par xm1math . Évalué à 9.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: Fonce!
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
[^] # Re: Fonce!
Posté par BAud (site web personnel) . Évalué à 4.
(sérieux, ça ne se dit plus « en sup' » ? je me fais déjà un si vieux taupin... piston même ?).
[^] # Pourquoi ?
Posté par Jeanuel (site web personnel) . Évalué à 3.
[^] # Re: Pourquoi ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Fonce!
Posté par Sébastien Wilmet . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Fonce!
Posté par Sébastien Wilmet . Évalué à 2.
Et il y a aussi l'hébergement du site web qui est fourni aveC.
[^] # Re: Fonce!
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
[^] # Re: Fonce!
Posté par Sébastien Wilmet . Évalué à 3.
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 boulde . Évalué à 4.
c'est possible chez github: http://pages.github.com/
[^] # Re: Fonce!
Posté par barmic . Évalué à 2.
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 JoeltheLion (site web personnel) . Évalué à 2.
# Note aux modos
Posté par Internaciulo . Évalué à 10.
[^] # Re: Note aux modos
Posté par Sébastien Wilmet . Évalué à 2.
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 Sébastien Wilmet . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
[^] # Re: Note aux modos
Posté par Maxime (site web personnel) . Évalué à 1.
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 Sébastien Wilmet . Évalué à 1.
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 Maxime (site web personnel) . Évalué à 2.
=> Je dis justement le contraire : Une heuristique n'est pas toujours une approximation.
[^] # Re: Note aux modos
Posté par Sébastien Wilmet . Évalué à 2.
[^] # Re: Note aux modos
Posté par Maxime (site web personnel) . Évalué à 3.
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 Thomas Douillard . Évalué à 4.
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 guepe . Évalué à 1.
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 Sébastien Wilmet . Évalué à 4.
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 grid . Évalué à 0.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
[^] # Re: Mouais, LyX comparé à ce genre de solution...
Posté par Jean Roc Morreale . Évalué à 1.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
[^] # Re: Mouais, LyX comparé à ce genre de solution...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Mouais, LyX comparé à ce genre de solution...
Posté par Sébastien Wilmet . Évalué à 2.
# Nous mes rotations
Posté par kursus_hc . Évalué à 10.
Si tu n'as pas le temps de recoder toutes les fonctionnalités, le mieux est de passer en 4.0.
[^] # Re: Nous mes rotations
Posté par Maclag . Évalué à 5.
Juste dommage que tu n'aies pas écrit ça un vendredi!
[^] # Re: Nous mes rotations
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
(non, je ne pouvais pas attendre vendredi)
# Genie
Posté par patrick_g (site web personnel) . Évalué à 3.
Est-ce que tu a choisi Vala après avoir évalué Genie ou pas ?
[^] # Re: Genie
Posté par Sébastien Wilmet . Évalué à 3.
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.