Que de changements depuis la version 2.0 sortie il y a un peu plus de neuf mois !
LaTeXila vise à avoir un logiciel équivalent à Kile ou Texmaker (tous les deux en Qt) pour GNOME. Initialement écrit en C, il y a eu une réécriture en Vala pour la version 2.0. La licence est la GPLv3.
Les nouveautés, en résumé :
- utilisation de Latexmk pour la compilation de documents (capture d'écran) ;
- structure du document pour voyager dans celui-ci rapidement (capture d'écran) ;
- une documentation (enfin !) ;
- LaTeXila est hébergé maintenant chez gnome.org.
Sommaire
Outils de constructions
Le but des outils de constructions est de compiler un document au format PDF, DVI ou PostScript. Si les outils inclus de base sont insuffisants, il est possible d'en créer de nouveaux. Le fonctionnement général est inspiré du plug-in LaTeX de Gedit, mais il y a eu de nombreuses améliorations.
La version 2.0 de LaTeXila utilisait Rubber pour compiler les documents. Un commentaire de la précédente dépêche m'a fait découvrir Latexmk, qui est maintenant utilisé par défaut avec la version 2.2. Latexmk est plus flexible, et on sait obtenir un meilleur diagnostic lorsqu'une erreur se produit.
Rubber est toujours disponible, et d'autres outils de constructions ont fait leur apparition : toutes les commandes de « bas niveau » tels que pdflatex, dvipdf, bibtex, etc.
Les commandes latex et pdflatex sont filtrées, pour n'afficher que les erreurs, avertissements et « bad box » (par exemple lorsque du texte dépasse de la marge).
Pour plus d'informations, consultez la toute nouvelle documentation (dans le menu « Aide »).
Structure du document
Une fonctionnalité qui manquait cruellement est l'affichage de la structure d'un document pour naviguer dans celui-ci rapidement.
La structure affiche bien entendu les chapitres, sections, sous-sections… Mais aussi d'autres éléments comme les labels, les figures ou les tables.
Mais même avec une structure, il peut être difficile de retrouver certains éléments dans un long document. LaTeXila a une solution pour ça. Il est possible d'afficher une liste reprenant seulement un type d'item (autre qu'une section). Donc si on recherche une image, au lieu de parcourir toute la structure, on affiche la simple liste, tout en ayant une vue complète de la structure. Si on clique sur l'image se trouvant dans la simple liste, l'élément correspondant est sélectionné dans l'arborescence complète, et on se retrouve au bon endroit dans le fichier.
Il y a une seconde innovation pour la structure. Comme avec Kile, quand on fait un clic droit sur un élément de la structure, il y a certaines actions possibles : sélectionner, supprimer, mettre en commentaire, etc. Deux nouvelles actions sont disponibles : décaler à gauche, et décaler à droite. Ces deux actions ne sont possibles que sur une section. Si on décale par exemple un chapitre vers la droite, il devient une section. Les sections du chapitre deviennent des sous-sections, et ainsi de suite.
Le décalage à gauche ou à droite peut être utile quand on veut restructurer notre document, mais aussi lors de copié-collés d'un document à l'autre.
gnome.org
Avant, SourceForge était utilisé en conjonction avec GitHub. Mais la gestion des traductions posait problème. Que les fichiers PO soient envoyés par mail, ou que ça se fasse par un « pull request », il fallait de toute façon intervenir manuellement à la moindre mise à jour.
Des plateformes comme Launchpad ou Transifex auraient permis de faciliter cette gestion. Mais cela aurait porté à trois le nombre de plate-forme utilisées, ce qui commence à être conséquent.
Tout migrer vers gnome.org s'est avéré une bonne solution. Ce n'est pas pour ça que LaTeXila est l'éditeur LaTeX officiel de GNOME. Il y a plein de petits (et moins petits) projets hébergés de la même façon : gitg, Banshee, gbrainy, gcompris, gparted, f-spot, etc.
Pour que LaTeXila s'intègre bien à GNOME Damned Lies (pour les traductions), ITS Tool est utilisé. Cela permet de traduire des fichiers XML grâce à un fichier PO. C'est utilisé notamment pour la documentation, qui est écrite en Mallard.
La plupart des autres projets GNOME n'utilisent pas encore ITS Tool, ils utilisent gnome-doc-utils, qui requiert les autotools. Mais comme LaTeXila utilise CMake, ce n'était pas possible. ITS Tool étant assez récent, il n'est malheureusement pas encore disponible dans toutes les distributions.
LaTeXila 3.0
La branche 2.x vient à peine de commencer que la version 3.0 est déjà prévue (mais dans longtemps).
LaTeXila est une application indépendante, ce n'est pas un greffon de l'éditeur de texte Gedit. C'est plus simple pour l'utilisateur, mais il y a pas mal d'inconvénients, comme l'absence de certaines fonctionnalités présentes dans Gedit (de base, ou via un greffon).
Le problème actuellement avec les greffons de Gedit, c'est que cela peut devenir une usine à gaz si on en active beaucoup à la fois. Imaginons maintenant qu'on désire réaliser plusieurs tâches en même temps, avec Gedit : par exemple, écrire un document en LaTeX, programmer en Vala, et écrire une dépêche pour LinuxFr. Si on a besoin de paramétrer Gedit de manière différente pour toutes ces tâches, ce n'est souvent pas possible.
Ce qu'il manque à Gedit, c'est un système de profils. On pourrait avoir un profil LaTeX, un profil Vala, un profil DLFP, etc. Chaque instance de Gedit avec un certain profil se comporterait comme une application indépendante.
Une fois que ce système de profils sera implémenté, il est prévu que LaTeXila devienne un greffon de Gedit. Comme c'est un changement suffisamment important, ce sera la version 3.0.
Malheureusement, le système de profils ne se profile pas à l'horizon. Il manque pour ça GSettingsList (qui fait partie de la GLib/GIO). C'est d'ailleurs pour ça que gnome-terminal (qui possède depuis longtemps un système de profils) utilise toujours GConf, le prédécesseur de GSettings.
Lors de la précédente dépêche, j'avais parlé de la libgedit, qui consistait à créer un framework spécialisé dans la création de nouveaux IDE en GTK+, le tout basé sur le code source de Gedit. Mais après discussion, ce projet est tombé à l'eau, au profit des profils.
En guise de conclusion
LaTeXila a innové sur plusieurs points : l'utilisation de Latexmk, et quelques améliorations permettant d'être encore plus productif grâce à la structure du document. La nouvelle version apporte aussi plein d'autres petites améliorations et corrections de bogues.
Malheureusement, une fonctionnalité importante manque toujours : la correction orthographique. Autre chose, c'est toujours GTK+ 2 qui est utilisé. La migration vers GTK+ 3 est prévue pour la prochaine version de LaTeXila. Pour connaître d'autres fonctionnalités manquantes, la feuille de route peut être consultée. Si la fonctionnalité en question n'y est pas, dites-le ;)
Aller plus loin
- LaTeXila (1102 clics)
- Complétion d'une balise (90 clics)
- Latexmk (84 clics)
- Dépêche de la version 2.0 (127 clics)
# Précisions
Posté par xm1math . Évalué à 10.
Pour info, quelques différences entre Texmaker et LaTeXila :
* Texmaker a un lecteur pdf intégré avec support de synctex et affichage des pages en mode continu
* Avec Texmaker, on a la structure, l'éditeur et le lecteur pdf dans une même fenêtre (le tout synchronisé grace à synctex) : voir ici et ici
* Avec Texmaker, on peut avoir deux documents cote à cote dans la même fenêtre afin de faciliter le copier/coller ou le glisser/déposer entre deux fichiers : voir ici et ici
* Texmaker intègre la correction orthographique (depuis bien longtemps) et la commande "R sweave" (pour les matheux)
Mais évidemment Texmaker (comme Kile et TeXworks) a l'épouvantable défaut d'être programmé en Qt...
[^] # Re: Précisions
Posté par Manuel Vonthron (site web personnel) . Évalué à 1.
À mon sens ce n'est pas Qt qui est un épouvantable défaut (au contraire, bien que "Gnomiste" j'apprécie la simplicité de coder avec Qt), c'est d'avoir des dépendances KDE, là d'accord, ça mérite châtiment. Mais ce n'est le cas que de Kile (ce qui ne veut pas dire que les autres sont sans défauts).
[^] # Re: Précisions
Posté par xm1math . Évalué à 9.
[^] # Re: Précisions
Posté par Sébastien Wilmet . Évalué à 4.
Pourquoi faire référence à Texmaker et à Kile ? Pcq je pense que la plupart des utilisateurs sur Linux utilisent soit l'un soit l'autre pour faire du LaTeX. En tout cas ceux qui préfèrent avoir un logiciel de type IDE avec interface graphique (d'autres préfèrent le plugin d'Emacs ou de Vim, c'est une question de choix).
Le but de LaTeXila n'est pas d'avoir une copie conforme de Texmaker ou Kile. Chacun a certainement des caractéristiques différentes, mais ce sont tous des logiciels du même type : des environnements latex intégrés.
Il est donc logique de citer les logiciels de référence dans le même domaine.
[^] # Re: Précisions
Posté par dinomasque . Évalué à 2.
"LaTeXila vise à avoir un logiciel équivalent à Kile ou Texmaker (tous les deux en Qt) pour GNOME."
"Le but de LaTeXila n'est pas d'avoir une copie conforme de Texmaker ou Kile."
J'avoue que la subtilité sémantique entre ces deux déclarations m'échappe encore.
BeOS le faisait il y a 20 ans !
[^] # Re: Précisions
Posté par Sébastien Wilmet . Évalué à 8.
équivalent ≠ copie conforme
Équivalent, dans le sens où LaTeXila est aussi un environnement LaTeX intégré utilisant un toolkit graphique. Le plugin de Vim par exemple n'est pas équivalent, bien qu'il ait le même but (écrire des documents en LaTeX).
Et LaTeXila n'est pas une copie conforme de Texmaker ou Kile. Déjà il manque beaucoup de fonctionnalités, je ne le cache pas, mais aussi je n'ai pas la même vision sur certaines choses.
Par exemple Texmaker contient des « wizards », c'est-à-dire des fenêtres de dialogue avec plein d'options pour insérer facilement un tableau par exemple. Je n'ai pas envie que LaTeXila contienne de wizards. Je préfère avoir une bonne complétion des balises et de leurs options (c'est très loin d'être parfait dans LaTeXila à ce niveau-là, ça demande encore beaucoup d'améliorations).
Une fonctionnalité très intéressante qui remplace pour moi avantageusement les wizards, c'est le plugin « Snippets » de Gedit. En gros l'utilisateur peut définir des raccourcis, comme taper « fig + TAB », ou bien un raccourcis clavier, et ce sera automatiquement remplacé par un morceau de texte, avec éventuellement des arguments. De cette manière on peut définir des raccourcis pour insérer rapidement une figure, une table, etc.
Au lieu de wizards, je préfère donc ce plugin couplé avec une bonne complétion.
Pour moi, il faut que l'utilisateur comprenne ce qu'il fait en LaTeX, au lieu d'utiliser des « clickodrome ». Si un étudiant pressé veut faire son rapport en LaTeX la veille de la remise des travaux, alors qu'il n'a jamais fait de LaTeX auparavant, c'est préférable pour lui d'utiliser Lyx. Mais c'est mon point de vue, et je respecte ceux qui préfèrent utiliser des wizards. Il en faut pour tous les gouts, c'est ça l'avantage d'avoir plusieurs logiciels équivalents mais qui diffèrent quand même sur certains points.
[^] # Re: Précisions
Posté par barmic . Évalué à 3.
S'il s'est trompé sur le fait que Texmaker ai une dépendance KDE, il n'a pas dis que Qt posait un problème.
La susceptibilité de certains KDEiste/Qtiste deviens de plus en plus lourde... Il n'a dis nul par que Qt posait un problème. Il a dis que la dépendance vers KDE était un problème. Lis avant de troller.
Il fait référence aux deux plus connus.
Il annonce clairement son objectif : l'intégration avec Gnome et notamment GEdit. L'idée étant de pouvoir sous gnome avoir un outil le plus proche pour coder, éditer des fichiers de configuration ou faire du LaTeX.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par Sébastien Wilmet . Évalué à 6.
Désolé, mais en relisant ton commentaire, je ne peux m'empêcher de rire. Le plus drôle c'est qu'il est évalué à 10 (mais bon la note d'un commentaire n'est que peu souvent pertinente de toute façon).
Il n'a jamais dit le contraire.
Je ne vois pas pourquoi tu as écris ça dans ton commentaire, dans le commentaire précédent il n'est fait aucun reproche à ce niveau-là.
Hum. Si ça c'est pas de la provocation gratuite…
De nouveau, ça n'a rien à voir avec le commentaire précédent, donc en fait j'ai plus l'impression que tu t'adressais à moi. C'est pour ça d'ailleurs que j'y ai déjà répondu.
Donc en gros, juste à cause de ce petit passage de la dépêche :
Tu en arrives (tout seul) à parler de « Qt-phobie », « intégristes gnomistes », et j'en passe.
Bon je sais pas, détends-toi, fume des fleurs, mais je ne viens pas vraiment sur LinuxFr pour ce genre de chamailleries, ni pour montrer qui a la plus grosse (je caricature, mais c'est plus ou moins ce que tu as fais dans le premier commentaire…).
[^] # Re: Précisions
Posté par Sébastien Wilmet . Évalué à 1.
Un lecteur PDF intégré n'est pratique que quand on n'est pas sûr de soi. Normalement, la plupart du temps, travailler directement dans le fichier .tex est amplement suffisant ÀMHA. Et quand on est pas sûr de soi, au lieu de chipoter et de trouver par hasard qqch qui nous convient, c'est beaucoup plus efficace d'aller lire la doc, comme ça la prochaine fois on sait directement ce qu'il faut faire.
C'est pareil en programmation. Compiler à tout bout de champ sans être sûr que notre code soit correct est une très mauvaise pratique, qui laisse souvent plein de bugs.
Mais même si on est à l'aise en latex, c'est clair qu'il y a des situations où on aime bien vérifier directement que le résultat soit correct, par exemple quand notre document est terminé, ou pour une formule mathématique assez longue. Mais avoir un programme externe qui s'ouvre ne me dérange pas trop. Rien n'empêche aussi d'avoir l'éditeur latex et le lecteur PDF côte à côte, mais dans ce cas c'est quand même plus pratique que le lecteur soit intégré.
Donc, pour moi, avoir un lecteur PDF intégré, c'est vrai que ce serait bien, mais ce n'est pas une priorité.
Pour le support de SyncTeX, il existe un plugin de Gedit pour ça. Donc quand latexila sera devenu aussi un plugin de Gedit, cette fonctionnalité sera disponible.
L'affichage des pages en mode continu, evince le fait très bien aussi.
Gedit 3 le permet aussi. C'est une des fonctionnalités présente de base dans Gedit qui n'est pas disponible dans latexila.
Je ne connais pas du tout R sweave. Je ne vois pas trop le lien avec la correction orthographique. Qu'est-ce qu'apporte Texmaker à ce niveau-là ?
Pour un utilisateur de KDE, ce n'est pas vraiment un défaut, c'est même un qualité ! Par contre pour un utilisateur de GNOME ou Xfce, c'est vrai que c'est un défaut. Il est possible que Texmaker ressemble à une appli GTK, mais il y aura toujours des différences majeures, sans compter le temps de lancement qui est plus long si c'est le premier programme en Qt qui est lancé. La fenêtre de dialogue pour ouvrir un nouveau fichier par exemple est complètement différent.
[^] # Re: Précisions
Posté par xm1math . Évalué à 3.
Ouah!! En voilà une nouvelle qui va faire plaisir aux utilisateurs de LaTeX : les afficheurs pdf/ps/dvi ne sont en fait pratique qu'aux débutants et aux gros nuls!
Pour info, sous Gnome, Qt utilise le sélecteur de fichier GTK!!! ( voir ici ) : votre argument tombe complètement à l'eau... Et il n'y a quasiment pas de latence quand on lance un programme purement Qt (les librairies Qt utilisées pésent environ 15 mo!).
Et d'un point de vue graphique, LaTeXila utilise des icones "KDE-like" venant de Kile : donc l'argument sur la cohérence graphique avec Gnome n'est pas utilisable non plus.
Mais il est clair qu'on est en plein dans la caricature et l'intolérance habituelle anti-Qt des intégristes gnomistes.
PS : je n'ai rien contre le programme en lui-même, mais uniquement contre sa présentation qui laisse croire que l'unique but du projet est de cloner en GTK un programme Qt, parce qu'utiliser un programme Qt sous gnome serait un péché mortel (A quand un autodafé de tous les programmes Qt ou Kde sur les distributions linux?).
Je le répéte : pourquoi ne pas simplement mettre en avant les caractéristiques et les qualités propres à LaTeXila au lieu de faire dans l'intégrisme anti-Qt (avec des arguments techniques qui ne tiennent pas la route) et de faire constamment référence (on y a droit à chaque nouvelle version de LaTeXila) à d'autres éditeurs alors que vous savez pertinemment qu'il y a d'énormes différences entre eux et LaTeXila...
[^] # Re: Précisions
Posté par Sébastien Wilmet . Évalué à 3.
Un des buts du LaTeX c'est de pouvoir se concentrer sur la structure et le contenu du document, pas sur sa mise en page. Les petits problèmes de mises en page se règlent en tout dernier lieu. C'est à ce moment-là qu'un lecteur PDF intégré est le plus intéressant.
On a sans doute une autre vision des choses, ce qui ne peut qu'être bénéfique pour les utilisateurs. J'ai donné plus haut un exemple avec les wizards.
Oui, ça a changé, avant ce n'était pas le cas, et pourtant c'est toujours à ça que je pense en premier quand je dois donner un exemple de mauvaise intégration de Qt dans GNOME.
Les seules icônes provenant de Kile toujours utilisées dans LaTeXila sont utilisées pour les templates. Personnellement je ne trouve pas ça du tout choquant. Il y a aussi les images des symboles, mais il n'y a absolument rien de spécifique à KDE dedans.
La seconde partie de la dépêche détaille je trouve suffisamment les qualités propres de LaTeXila.
Un des buts de LaTeXila est qu'elle soit vraiment bien intégrée à GNOME. Un logiciel en Qt n'obtiendra jamais une aussi bonne intégration à GNOME qu'un logiciel en GTK+, c'est un fait. La simple apparence n'est pas la seule chose. Il y a par exemple aussi l'utilisation de GSettings (avec le backend dconf).
[^] # Re: Précisions
Posté par barmic . Évalué à 2.
Fais gaffe comparer un logiciel en GTK+ à un logiciel en Qt sur de l'intégration c'est mal vu ici.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par Altor . Évalué à 4.
Ce qui est mal vu, c'est que dans un cas (qt/kde), les développeurs font beaucoup d'effort pour que les applications qt s’intègrent bien sous gnome ET que les applications gtk s’intègrent bien sous kde (cf oygen-gtk). Par contre, gtk/gnome ne fait pas beaucoup d'effort.
[^] # Re: Précisions
Posté par barmic . Évalué à -4.
Ouai donc c'est des réponses d'aigris qui ne veulent rien entendre à partir du moment que ça parle GTK.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par Altor . Évalué à 1.
Alors, ton premier commentaire :
Ensuite j'explique pourquoi et là, un magnifique raccourci :
Donc pour bien mettre les points sur les i, certaines personnes râlent lorsque ça parle de gtk ET d'intégration.
[^] # Re: Précisions
Posté par barmic . Évalué à 3.
GTK est mieux intégrer à Gnome que Qt et ce même si l'intégration de Qt n'est pas si mauvaise, même si les développeurs Qt se saignent pour faire les choses le mieux possibles. Considérer cette vérité comme du troll c'est se voiler la face et être aigris.
Après ça n'implique pas que cet état de fait ne soit pas de la faute d'un éventuel autisme de la part des développeurs Gnome (j'en sais rien).
Qt as t'il pour but de permettre de faire des plugins GEdit, à s'intégrer à GSettings ou je ne sais quel autre gnomisme ?
Donc je persiste : ce sont des remarques d'aigris qui ne veulent pas entendre parler de GTK.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par Altor . Évalué à 3.
Gnome est écrit en C/GTK+, encore heureux que GTK est mieux intégré. Après, le seul problème dont je parle, c'est que pour les développeurs gnome/gtk, l'intégration sous d'autre environnement n'est même pas envisagée. Je trouve que pour un OS (linux) qui prône l’interopérabilité, si l'un des principaux environnements de bureau ne fait aucun effort c'est préjudiciable pour le long terme.
Personnellement, gtk ou qt je m'en fous tant que je peux mixer le meilleur des deux mondes sur mon PC.
[^] # Re: Précisions
Posté par barmic . Évalué à 2.
C'est ce qui était remis en cause dan les premiers commentaires.
La dépêche dis que LaTeXila est une texmaker plus intégré à Gnome et il se fait pourrir.
Tu es resté dans l'ancien paradigme, c'est plus d'actualité. L'interopérabilité ça nuit à la créativité. Tu n'a pas entendu parler de systemd ? Tu verra un gnome intégré à systemd ce que ça va donner.
Je suis d'accord avec toi sur le fait que le projet gnome est généralement autiste.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par Sébastien Wilmet . Évalué à 2.
Bon il faut peut-être mettre les choses au clair.
Dire que GNOME a un comportement autiste, ce n'est vraiment pas respectueux. On pourrait dire exactement la même chose envers LaTeXila sur le fait que ce ne soit pas installable sur Windows ou MacOS X. Mais comme on est ici sur LinuxFr, ça va, on ne me traite pas d'autiste. Si ça tombe, en une journée de travail, pour quelqu'un qui s'y connait bien, c'est faisable de porter LaTeXila sur un système d'exploitation exotique. Mais pourquoi ça n'a jamais été fait ? Je pourrais tenter de le faire moi-même. Mais pour ça il faut premièrement que j'ai accès à l'OS en question, et il faut que je passe du temps pour l'installation, et du temps pour le portage en lui-même. D'autres personnes peuvent s'atteler à la tâche, j'en serais ravi. Mais personne ne s'est encore manifesté. La priorité pour moi est tout d'abord de satisfaire mes propres besoins, et ceux des personnes utilisant la même chose que moi (GNU/Linux, GNOME).
Les journées n'ont que 24h, et ça arrive aussi d'avoir une vie IRL. Aussi, beaucoup de développeurs contribuent parce qu'ils en ont simplement l'envie, sur leur temps libre. Donc pour eux, généralement ce n'est pas une mission. D'autres évidemment sont payés pour ça, là c'est différent. Mais les intérêts des entreprises peuvent être différents de l'intérêt de certains utilisateurs.
Donc pour moi le fait qu'une application GTK+ ne s'intègre pas aussi bien dans KDE qu'une application Qt dans GNOME, ce n'est pas du tout dû au fait que les développeurs seraient contre, ou qu'ils ne veulent pas entendre parler de portabilité etc (ce que tu sous-entend je pense par le fait qu'ils seraient autiste). C'est dû à un manque de main d'œuvre. C'est normal que la priorité, pour eux, est que les utilisateurs de GNOME soient tout d'abord satisfaits.
Je ne connais pas bien Qt, mais je pense que plus de développeurs sont payés pour travailler dessus (Nokia, …). Une autre différence est peut-être que Qt est un projet presque complètement indépendant de KDE (quelqu'un pour confirmer ?). Tandis que GTK+ fait clairement partie du projet GNOME.
Pour systemd, c'est différent. Lennart est clairement contre la portabilité, mais ça se comprend, puisque plein de choses spécifiques à Linux sont utilisées. Essayer de rendre systemd portable rendrait le code ingérable.
Si GNOME utilise systemd, et si je ne dis pas de bêtise, ça ne se fera que de manière indirecte via une interface. systemd serait une implémentation de cette interface, qui est optimisée pour Linux. Mais rien n'empêche d'écrire une implémentation portable de cette interface (en gros, adapter le code actuel gérant la session de GNOME pour qu'il colle à l'interface). Évidemment c'est bcp plus facile à dire qu'à faire, et ce qu'il risque de se passer est que systemd soit la seule implémentation de l'interface pendant une ou plusieurs versions de GNOME. À ce moment-là, peut-être que les développeurs ne décideront d'utiliser systemd que quand l'implémentation portable sera écrite. Tout dépend de ce que décident les mainteneurs des modules impactés. Wait and see :)
[^] # Re: Précisions
Posté par barmic . Évalué à 4.
Non parce que (même si je ne l'ai pas dis plus haut), je pense plutôt à la manière dont les choses se passent avec Freedesktop comme ça :
https://linuxfr.org/users/gnumdk/journaux/putain-de-nazis-de-linterface
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par Sébastien Wilmet . Évalué à 1.
Rejeter entièrement la faute sur GNOME, c'est du simple troll. La situation est bien plus complexe que ça, comme l'explique très bien ce billet de Dave Neary, dont le premier point est :
[^] # Re: Précisions
Posté par barmic . Évalué à 4.
Après il y en a d'autres des exemple comme les déclarations de Jon McCann.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par xm1math . Évalué à 4.
En effet. Ce qui n'est pas un défaut à condition de ne pas diffuser de fausses informations sur ce toolkit.
Ce n'est pas peut-être. Qt est complètement indépendant de Kde et fonctionne sur une multitude de système.
Ah bon! Vous semblez ignorer que :
- bon nombre d'applis gtk peuvent fonctionner sans dépendance envers gnome (gimp, abiword, gnumeric,...)
- il y a même un environnement de bureau complet (xfce) codé en gtk et qui est indépendant de gnome
- que des applis gtk peuvent même fonctionner sur windows (et sans gnome, bien évidemment)
[^] # Re: Précisions
Posté par Sébastien Wilmet . Évalué à 3.
Merci pour cette confirmation.
Pour GTK+, ce n'est pas pcq c'est un des principaux modules du projet GNOME, que c'est utilisé que par et pour GNOME. Mais le développement de GTK est quand même plus orienté pour convenir en premier lieu à GNOME, ce qui est logique, mais qui n'est pas le cas pour Qt/KDE.
C'est sans doute une des raisons pour lesquelles Qt est plus facile pour faire des applis portables.
[^] # Re: Précisions
Posté par barmic . Évalué à 2.
Pour en rajouter, si on ne peux plus faire un logiciel en GTK et parler de la "concurrence" Qt/KDE sans se faire taxer d'intégriste, il y a un vrai problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par Altor . Évalué à 1.
Je ne pense pas t'avoir traité d'intégriste, et AMHA, il faut de la concurrence sinon il n'y a plus d'innovation. C'est justement cette concurrence que j'aime dans le libre. Une application de musique, mail, pdf ou autre ne me convient pas ? Je peux en changer très facilement (formats standards, passerelles …).
[^] # Re: Précisions
Posté par barmic . Évalué à 2.
Voila ce qu'on peut lire plus haut (c'est pas toi qui l'a écris et c'était pas contre moi mais c'est ce dont je voulais parler)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par xm1math . Évalué à 2.
Il n'a jamais été question de ça. Relisez mes propos :
"Qu'il y ait d'autres éditeurs LaTeX en GTK ne pose aucun problème (comme gummi )..."
(J'ai même fait de la pub à un autre éditeur latex en gtk!)
"je n'ai rien contre le programme en lui-même, mais uniquement contre sa présentation qui laisse croire que l'unique but du projet est de cloner en GTK un programme Qt, parce qu'utiliser un programme Qt sous gnome serait un péché mortel..."
Je vous rassure, je suis pour la liberté et pour le pluralisme.
Après tout, s'il y a des volontaires, pourquoi ne pas faire des versions Gtk de vlc, scribus, lyx, etc... parce qu'ils ont le malheur d'être codé en Qt? Et réciproquement, pourquoi ne pas faire des clones en Qt des programmes phares Gtk? Comme ça tous les partisans de la "pureté toolkitisque" seront contents.
Fort heureusement, bon nombre de distrib ont moins d'œillères et savent proposer des applis Qt et Gtk ensemble de façon harmonieuse.
[^] # Re: Précisions
Posté par barmic . Évalué à 3.
Le problème c'est de ne pas avoir lu ce qui est écris mais ce que vous vouliez lire. Il dit clairement qu'il vise une intégration forte dans Gnome allant jusqu'à s'interfacer avec GEdit. Chose qui est peut être possible en Qt, mais qui n'est pas le choix le plus logique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Précisions
Posté par xm1math . Évalué à 1.
Ah bon! La présentation commence par cette phrase :
Ce qui sous-entend clairement que :
- LaTeXila se présente comme un "équivalent" de Kile et Texmaker. Ce qui n'est pas exact d'un point vue technique. D'autant plus, que plus loin, l'auteur de LaTeXila dit clairement qu'il veut faire un truc fonctionnant différemment....
- Texmaker et Kile ne pourrait pas fonctionner correctement sous gnome. Ce qui est faux, comme je l'ai prouvé avec les vidéos de texmaker faites sous gnome. Et réciproquement, les logiciels Gtk fonctionnent très bien dans des environnements autres que Gnome (Kde, Xfce...)
Comme je l'ai déjà dit 3 fois, je ne critique que la présentation du logiciel.
Pourquoi ne pas dire tout simplement, (comme gummi, autre éditeur LaTeX en Gtk dont j'ai fait la pub), que LaTeXila est un éditeur/IDE LaTeX écrit en Gtk (et futur plugin pour gedit) et mettre en avant ses spécificités et qualités propres (ce que j'ai déjà dit 2 fois)?
Je n'ai ni critiqué Gtk, ni l'existence d'autres éditeurs LaTeX sous Gtk (pour ma part, je suis pour le pluralisme ; j'utilise tous les jours des softs en Gtk, Qt, wxwidget,... et ça ne me gêne absolument pas)
Le monde des logiciels libres est beaucoup plus divers et ouvert que la vision étroite et parcellaire que certains proposent ici.
[^] # Re: Précisions
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Non, là tu interprètes. LaTeXila est un IDE LaTeX pôur GNOME, point. Kile tourne sous GNOME, mais n'est pas bien intégré, alors que LaTeXila vise l'intégration.
[^] # Re: Précisions
Posté par xm1math . Évalué à -2.
Cette présentation ne me gêne absolument pas (tant qu'on ne glisse pas un bon vieux troll anti-qt derrière).
[^] # Re: Précisions
Posté par GeneralZod . Évalué à 5.
+1
Même si Qt a fait un excellent boulot, reste encore quelques points à travailler dans le look'n'feel des widgets même si c'est parfois subtil.
Ceux qui n'en sont pas convaincu peuvent s'amuser à comparer les frontends Gtk+2 et Qt4 de transmission qui essaient de fournir une UI similaire, même si c'est plutôt réussi, on arrive quand même distinguer les deux à l'oeil nu.
# Complétions
Posté par rgugliel . Évalué à 3.
Hello!
Je me demande si les deux fonctionnalités (essentielles à mon goût) sont prévues:
- Complétion des environnements (on met \begin{schtroumpf} et un retour chariot met le \end{stroumpf} indente et place le curseur au milieu).
- Possibilité de donner une liste d'environnements pour la complétion (comme dans kile, dans les *.cwl, si je me souviens bien).
Merci!
Rafaek
[^] # Re: Complétions
Posté par Sébastien Wilmet . Évalué à 1.
C'était une nouveauté de la version 2.0. Un contributeur a amélioré un petit peu la complétion des environnements de listes, en ajoutant « \item » ou « \item[] » en plus.
Non, ce n'est pas encore possible de rajouter de nouvelles balises ou environnements pour la complétion.
[^] # Re: Complétions
Posté par rgugliel . Évalué à 1.
Merci pour la réponse!
> C'était une nouveauté de la version 2.0. Un contributeur a amélioré un petit peu la complétion des environnements de listes, en ajoutant « \item » ou « \item[] » en plus.
Mais donc pas possible de manière générique pour tous les environnements, dommage.
# Paquet Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Je suis en vacances, mais dès que je rentre et que j'ai un peu de temps, je m'y mets : si tout va bien, LaTeXila 2.2 sera bientôt dans Debian unstable.
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet . Évalué à 2.
Ça risque de ne pas être si simple, malheureusement. Je ne pense pas que ITS Tool soit déjà packagé sur Debian. Mais ITS Tool est plus ou moins le successeur de gnome-doc-utils si j'ai bien compris, donc de plus en plus de modules de GNOME l'utiliseront (bien que ce ne soit pas du tout spécifique à GNOME).
Autre chose, j'ai finalement opté pour une seule tarball qui contient le code source C généré (comme avant donc), mais il n'y a plus de commit dans Git qui correspond exactement au tarball, puisque c'est déconseillé de mettre dans Git des fichiers générés.
Sinon, j'ai créé un ebuild pour Gentoo, j'espère que ça ne prendra pas trop longtemps pour qu'il débarque dans l'arbre de Portage.
Bonnes vacances !
[^] # Re: Paquet Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Rah. Bon, eh bien on se passera de documentation, si je n'ai pas moyen de la compiler.
Ça, ce n'est pas cool, mais au pire, je les ferai moi-même, les commits en question, comme pour les autres paquets que je gère dont les auteurs ont cru bon de produire des tarballs qui ne correspondent pas au source, une habitude détestable à mon avis. Mais la vraie question, c'est : pourquoi fournir les fichiers C générés dans le tarball ? Cela supprime la dépendance à Vala, mais à quoi cela sert-il vu que Vala n'est pas un outil exotique et que LaTeXila dépend déjà d'autres outils qui sont bien plus pointus ? ITS Tool, par exemple…
[^] # Re: Paquet Debian
Posté par barmic . Évalué à 3.
Ça ne me semble pas être une mauvaise idée de limiter le nombre de dépendance (et les simplifier). Je crois que c'est même une recommandation du projet Vala de distribuer des sources C et pas Vala.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Paquet Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
C'est une recommandation qui me semble douteuse, du moins associée à celle de GNOME de ne pas stocker sous Git des fichiers générés. Parce que le résultat, c'est des tarballs qui ne correspondent pas du tout au contenu du VCS, ce qui est très désagréable pour un distributeur.
La solution que j'applique en tant que mainteneur de paquet, c'est d'assumer moi-même le travail d'adaptation en construisant les commits manquants. Mais je considère que ce travail ne devrait pas m'incomber (et me décomber).
[^] # Re: Paquet Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
En fait non. On va empaqueter ITS Tool. :-)
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet . Évalué à 3.
C'est utilisé entre autres pour les traductions de la documentation, mais pas seulement. Il y a aussi les traductions des templates et des outils de constructions.
Donc comme tu l'as dit plus bas, le mieux est d'empaqueter ITS Tool. De toute façon il sera normalement de plus en plus utilisé à l'avenir. Hé, LaTeXila est à la pointe de la technologie ! (bon, il ne faut pas dire trop fort que GTK+ 2 est toujours utilisé ;)
En-dehors des fichiers *.c, il n'y a vraiment pas beaucoup de différences (2 lignes).
Vala n'est pas exotique, mais ici c'est la version 0.12.x >= 0.12.1 qui doit être utilisé (donc pas 0.13 ou supérieur, ni les versions précédentes). C'est ça qui est exotique. Sur Gentoo ça ne pose aucun problème puisque plusieurs versions de Vala peuvent installées en parallèle. Mais ce n'est pas le cas de Fedora par exemple.
Pour Fedora, la version 15 utilise Vala 0.12, donc là on peut compiler à partir du Vala. Mais si on veut packager latexila pour F14 (Vala 0.10) ou F16 (Vala 0.14), ce n'est pas possible. Dans ce cas-là, si le C n'était pas distribué avec la tarball, ils devraient le fournir via un patch par exemple, ou faire en sorte de pouvoir installer plusieurs versions de Vala en parallèle.
[^] # Re: Paquet Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Compris pour Vala. Je me permets donc de suggérer de faire, en amont, ce que je fais moi-même quand j'y suis obligé, comme ici :
À savoir : avoir une branche dont le contenu corresponde exactement aux tarballs distribués, à l'exception éventuelle de fichiers .gitignore, branche sur laquelle aucun développement n'aurait lieu, mais remise à jour à chaque nouvelle version. Une telle branche peut évidemment être séparée en plusieurs en cas de maintenance de version antérieure, par exemple :
La cohérence des étiquettes est le point important, plus que celle des branches elles-mêmes, à vrai dire.
[^] # Re: Paquet Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Je précise encore une fois que je le fais moi-même si c'est nécessaire, mais j'ai l'impression que ça ne devrait pas être à moi de le faire, pour diverses raisons :
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet . Évalué à 1.
C'est ce que je faisais avant avec les branches releases-x-y, qui correspondaient exactement aux tarballs, et qui étaient parallèles aux branches latexila-x-y. C'est ça qui était reproché.
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet . Évalué à 1.
Enfin, ce que je veux dire, c'est que peut importe la branche dans laquelle le C se trouve, il ne devrait pas être dans git.
[^] # Re: Paquet Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Je vois, c'est une contrainte pénible de GNOME, donc. Eh bien, ça revient simplement à déplacer et à multiplier ce travail sur chaque distribution utilisant Git, tant pis…
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet . Évalué à 2.
Je comprends tout à fait l'utilité d'utiliser Git ou tout autre gestionnaire de versions pour gérer le packaging.
Par contre ce que je ne comprends pas, c'est de vouloir avoir dans Git l'équivalent du tarball. Pour un paquet RPM ou un ebuild de Gentoo, une simple URL vers le tarball suffit. Ce qui se trouve dans Git à ce moment-là, c'est uniquement ce qui est spécifique au paquet : le .spec pour RPM, le .ebuild et d'autres petites choses pour Gentoo.
Je ne sais pas comment est construit un paquet DEB, mais je ne pense pas que beaucoup de distribs ont besoin d'avoir dans Git l'équivalent du tarball.
[^] # Re: Paquet Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Ah, c'est vrai que j'avais oublié d'expliquer cela. Ce n'est effectivement pas une nécessité, tout comme il n'est pas non plus nécessaire d'utiliser un gestionnaire de version d'ailleurs. C'est simplement pratique : nous disposons d'un outil nommé pristine-tar qui permet de stocker les informations nécessaires à la reconstruction du tarball exact dans le gestionnaire de versions, ce qui permet de tout mettre dedans et simplifie d'autant la gestion du paquet.
pristine-tar fonctionne en stockant dans une branche détachée — c'est à dire sans origine commune avec quelque autre branche — quelques informations : un commit d'origine proche du contenu du tarball, la compression utilisée et un delta binaire entre le tarball ainsi généré et l'original. On essaie de minimiser ce delta en utilisant un commit d'origine aussi proche que possible du contenu du tarball : un fichier de trop, tel un .gitignore ne posera pas de problème, mais plusieurs gros fichiers produiront un gros delta, ce qui n'est ni élégant ni efficace.
Indépendamment de la gestion de version, un paquet Debian source est constitué grosso modo de deux fichiers : le tarball d'origine et une archive contenant les fichiers spécifiques au paquet Debian. Lors de la décompression de ce paquet source, le tarball d'origine est simplement extrait, et les fichiers spécifiques à Debian sont placés dans un répertoire debian/, pour former ce que j'appellerais un répertoire de travail de paquet Debian. Lorsqu'on choisit de travailler sous contrôle de version, on y stocke le plus souvent tout le contenu du répertoire de travail, comprenant donc le contenu du tarball d'origine et le répertoire debian/.
Le dépôt de contrôle de version contient donc de quoi travailler, mais pas de quoi reconstruire le tarball d'origine, donc a fortiori pas de quoi reconstruire le paquet source qui comprend ce tarball d'origine. pristine-tar pallie cela, en versionnant également de quoi reconstruire ce tarball.
[^] # Re: Paquet Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Comme je l'ai détaillé plus haut, Debian non plus, mais il est pratique de pouvoir le faire, et c'est considéré comme une bonne chose.
[^] # Re: Paquet Debian
Posté par Sébastien Wilmet . Évalué à 1.
OK, merci pour ces explications, je comprends mieux maintenant. Mais on peut imaginer d'autres systèmes plus simples (si c'est scripté), dans ce cas.
Par exemple, je veux créer un tout nouveau paquet debian pour latexila. Je demande au script de m'initialiser un nouveau dépôt git avec dedans un dossier debian/ vide, et la tarball désarchivée (on donne le lien vers le tarball). On écrit les fichiers qu'il faut dans debian/, on commit, on crée éventuellement des branches, etc.
Le principe est d'avoir un dépôt complètement différent de celui de l'upstream. Quand une nouvelle version sort, on demande au script de prendre la nouvelle version (là, seul le numéro de version serait nécessaire, pas le lien complet). Ce que ferait simplement le script, c'est de tout supprimer sauf le répertoire debian/, et de désarchiver le nouveau tarball.
Ce système suppose qu'on a pas besoin de l'historique complet du dépôt Git upstream. À chaque nouvelle version, il y aurait juste un gros commit, avec plusieurs petits commits contenant les modifications nécessaires dans debian/.
Qu'est-ce qui ne va pas à ce système pour ne pas l'utiliser ? Pour moi ça me semble plus simple, et plus générique.
[^] # Re: Paquet Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Plus générique, oui, et c'est d'ailleurs ce qui se fait en général lorsque le développeur amont ne fournit pas de dépôt de versions, grâce à des outils faits pour automatiser cela, mais pas plus simple. L'historique amont m'est utile pour diverses raisons, par exemple :
git merge, opération à laquelle je suis habituée.Non, si je dois maintenir moi-même un contenu de dépôt semblable au tarball, cela ne me pose pas plus de problème que ça, je trouve juste cela dommage, mais je le ferai avec une branche parallèle basée sur celles de ton dépôt.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.