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.
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.
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é.
Rah. Bon, eh bien on se passera de documentation, si je n'ai pas moyen de la compiler.
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é ;)
Ça, ce n'est pas cool, mais au pire, je les ferai moi-même, les commits en question
En-dehors des fichiers *.c, il n'y a vraiment pas beaucoup de différences (2 lignes).
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
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.
Ce n'est pas peut-être. Qt est complètement indépendant de Kde
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.
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 :
Je ne connaissais pas le nombre de Graham (c'est tout simplement impressionnant !), mais la série du nombre parfait ne fait pas du tout le poids (en grammes).
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 :)
L'objectif est bien d'avoir une gestion séparée des versions fournies par GSRC et celles fournies par la distribution, en installant par exemple les outils dans un sous-répertoire de son home directory.
Ah oui, donc le principe est assez proche de jhbuild, qui est utilisé intensivement par les développeurs de GNOME pour installer la version en développement de certains modules, sans interférer avec ce qui est installé par la distribution.
Ç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.
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 souventpertinente de toute façon).
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
Texmaker (comme TeXworks) n'a aucune dépendance avec les librairies de KDE
Il n'a jamais dit le contraire.
Les applis Qt peuvent s'intégrer à gnome, comme le montre cette video de Texmaker réalisée sous gnome-shell/fedora 15
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à.
(au contraire, bien que "Gnomiste" j'apprécie la simplicité de coder avec Qt)
La "Qt-phobie" de certains intégristes gnomistes devient de plus en plus lourde... […]
Hum. Si ça c'est pas de la provocation gratuite…
Qu'il y ait d'autres éditeurs LaTeX en GTK ne pose aucun problème (comme gummi ), mais qu'on évite de faire référence à chaque présentation de LaTeXila à Texmaker ou à Kile alors que ces éditeurs ont des caractéristiques très éloignées.
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 :
LaTeXila vise à avoir un logiciel équivalent à Kile ou Texmaker (tous les deux en Qt) pour GNOME
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…).
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!
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.
Pour info, sous Gnome, Qt utilise le sélecteur de fichier GTK!!!
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.
Et d'un point de vue graphique, LaTeXila utilise des icones "KDE-like" venant de Kile
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.
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
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).
É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.
mais qu'on évite de faire référence à chaque présentation de LaTeXila à Texmaker ou à Kile alors que ces éditeurs ont des caractéristiques très éloignées.
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.
Texmaker a un lecteur pdf intégré avec support de synctex et affichage des pages en mode continu
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.
Avec Texmaker, on peut avoir deux documents cote à cote dans la même fenêtre
Gedit 3 le permet aussi. C'est une des fonctionnalités présente de base dans Gedit qui n'est pas disponible dans latexila.
Texmaker intègre la correction orthographique (depuis bien longtemps) et la commande "R sweave" (pour les matheux)
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à ?
Mais évidemment Texmaker (comme Kile et TeXworks) a l'épouvantable défaut d'être programmé en Qt...
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.
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.
Possibilité de donner une liste d'environnements pour la complétion
Non, ce n'est pas encore possible de rajouter de nouvelles balises ou environnements pour la complétion.
En fait il se peut aussi très bien que GNOME 3 ne soit pas dans un nouveau slot dans Gentoo. Mais dans ce cas-là, GNOME 2 restera quand-même disponible (enfin, j'espère), puisqu'il peut y avoir plusieurs versions différentes dans un même slot (mais une seule version peut être installée par slot).
Dans ce cas-là il ne faut pas bloquer le slot 3, il faut bloquer les versions supérieures ou égales à 3.
Bref, Gentoo a plusieurs possibilités pour que GNOME 2 reste dans portage pendant encore un certain temps. Et ça s'applique bien sûr à tout autre logiciel. C'est la façon dont le gestionnaire de paquet (Portage) est fait.
Son seul défaut, à mes yeux ? Le principe de la rolling release, très appréciable par ailleurs, nous condamne à Gnome 3, à moins de bloquer la date des dépôts
Je ne sais pas exactement ce qu'implique de bloquer la date des dépôts (si ça s'applique pour tous les paquets, ou juste ceux de gnome, ou … ?).
En tout cas pour moi le défaut dans ce cas-ci n'est pas la rolling release. Le défaut c'est qu'il n'est apparemment pas possible d'installer en parallèle plusieurs versions d'un même logiciel avec Arch. Gentoo fait ça très bien avec les « slots » (mais le packageur a dû explicitement définir les différents slots, ça ne peut pas se faire facilement pour n'importe quel paquet).
Bon là Gentoo a un autre défaut, c'est que GNOME 3 n'est toujours pas disponible dans l'arbre officiel de portage (il faut passer par l'overlay gnome). Mais je suis presque certain que quand ce sera le cas, la version 2 restera dans un slot séparé pendant encore quelques temps. Il serait donc possible de bloquer le slot « 3 » et de rester sur le slot « 2 ». C'est déjà le cas pour les bibliothèques importantes (GTK+, …), dont la version 3 est présente dans portage, mais en testing.
Et s'ils pouvaient aussi arrêter de spamer toutes les pages wikipedia traitant de sujets dont ils ont parlé au moins une fois, ça serait bien aussi…
Ah je ne connaissais pas cette pratique. Par contre ce que j'ai remarqué en lisant l'article sur les bitcoins, qui semblait à première vue intéressant, c'est qu'ils ont fait un gros copier/coller de certaines parties, en provenance du site bitcoin.fr.
Donc ça ne m'étonnerait pas qu'ils fassent aussi des copiers/collers de wikipédia. C'est le chat qui se mord la queue…
Souvent, quand on veut se documenter sur un logiciel, on est intéressé seulement par faire une chose bien précise. Un manuel, qui s'apparente à un livre, c'est plutôt fait pour être lu du début à la fin.
C'est pour ça qu'une documentation orientée « topiques » est souvent plus simple pour l'utilisateur. Au lieu de ressembler à un livre, ça ressemble plus à une FAQ. Chaque topique peut être lu indépendamment des autres, avec si nécessaire des liens vers d'autres pages.
GNOME a migré déjà pas mal de sa documentation sous forme de topiques, en langage Mallard. Au Desktop Summit il y a eu une conférence sur le sujet, et l'auteur en a fait un résumé sur son blog.
[^] # Re: Paquet Debian
Posté par swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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 swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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 swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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 swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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 swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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: Précisions
Posté par swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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 swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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: une série qui grandit vite
Posté par swilmet . En réponse au journal Qui à la plus grande. Évalué à 1.
Je ne connaissais pas le nombre de Graham (c'est tout simplement impressionnant !), mais la série du nombre parfait ne fait pas du tout le poids (en grammes).
C'est d'ailleurs marrant de tomber sur Knuth.
[^] # Re: Précisions
Posté par swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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 :)
[^] # jhbuild
Posté par swilmet . En réponse à la dépêche Le projet GNU s'enrichit d'un gestionnaire de paquets. Évalué à 2.
Ah oui, donc le principe est assez proche de jhbuild, qui est utilisé intensivement par les développeurs de GNOME pour installer la version en développement de certains modules, sans interférer avec ce qui est installé par la distribution.
[^] # Re: Paquet Debian
Posté par swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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: Précisions
Posté par swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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 swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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 swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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 swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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 swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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: Complétions
Posté par swilmet . En réponse à la dépêche LaTeXila 2.2, environnement LaTeX intégré pour GNOME. É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: KISS ?
Posté par swilmet . En réponse à la dépêche Nouvel installateur pour ArchLinux. Évalué à 4.
En fait il se peut aussi très bien que GNOME 3 ne soit pas dans un nouveau slot dans Gentoo. Mais dans ce cas-là, GNOME 2 restera quand-même disponible (enfin, j'espère), puisqu'il peut y avoir plusieurs versions différentes dans un même slot (mais une seule version peut être installée par slot).
Dans ce cas-là il ne faut pas bloquer le slot 3, il faut bloquer les versions supérieures ou égales à 3.
Bref, Gentoo a plusieurs possibilités pour que GNOME 2 reste dans portage pendant encore un certain temps. Et ça s'applique bien sûr à tout autre logiciel. C'est la façon dont le gestionnaire de paquet (Portage) est fait.
[^] # Re: KISS ?
Posté par swilmet . En réponse à la dépêche Nouvel installateur pour ArchLinux. Évalué à 4.
Je ne sais pas exactement ce qu'implique de bloquer la date des dépôts (si ça s'applique pour tous les paquets, ou juste ceux de gnome, ou … ?).
En tout cas pour moi le défaut dans ce cas-ci n'est pas la rolling release. Le défaut c'est qu'il n'est apparemment pas possible d'installer en parallèle plusieurs versions d'un même logiciel avec Arch. Gentoo fait ça très bien avec les « slots » (mais le packageur a dû explicitement définir les différents slots, ça ne peut pas se faire facilement pour n'importe quel paquet).
Bon là Gentoo a un autre défaut, c'est que GNOME 3 n'est toujours pas disponible dans l'arbre officiel de portage (il faut passer par l'overlay gnome). Mais je suis presque certain que quand ce sera le cas, la version 2 restera dans un slot séparé pendant encore quelques temps. Il serait donc possible de bloquer le slot « 3 » et de rester sur le slot « 2 ». C'est déjà le cas pour les bibliothèques importantes (GTK+, …), dont la version 3 est présente dans portage, mais en testing.
[^] # Re: Le site du zero
Posté par swilmet . En réponse au journal éclaircissement sur les WM et les DM. Évalué à 2.
Ah je ne connaissais pas cette pratique. Par contre ce que j'ai remarqué en lisant l'article sur les bitcoins, qui semblait à première vue intéressant, c'est qu'ils ont fait un gros copier/coller de certaines parties, en provenance du site bitcoin.fr.
Donc ça ne m'étonnerait pas qu'ils fassent aussi des copiers/collers de wikipédia. C'est le chat qui se mord la queue…
[^] # Re: Tu parles de quoi ?
Posté par swilmet . En réponse au journal éclaircissement sur les WM et les DM. Évalué à 1.
Window Manager, par exemple metacity (utilisé par GNOME 2), kwin (KDE), mutter (GNOME 3), xfwm (Xfce).
Desktop Manager, par exemple GNOME, Xfce, KDE, etc.
Si je ne dis pas de bêtise, Awesome et compagnie peuvent être catégorisé dans les Window Manager aussi.
[^] # Re: Documentation orientée topiques
Posté par swilmet . En réponse à la dépêche Scribus : nouveau manuel libre. Évalué à 1.
En anglais : « topic-oriented help ».
Donc « documentation orientée topiques » me semble une bonne traduction.
# Documentation orientée topiques
Posté par swilmet . En réponse à la dépêche Scribus : nouveau manuel libre. Évalué à 3.
Souvent, quand on veut se documenter sur un logiciel, on est intéressé seulement par faire une chose bien précise. Un manuel, qui s'apparente à un livre, c'est plutôt fait pour être lu du début à la fin.
C'est pour ça qu'une documentation orientée « topiques » est souvent plus simple pour l'utilisateur. Au lieu de ressembler à un livre, ça ressemble plus à une FAQ. Chaque topique peut être lu indépendamment des autres, avec si nécessaire des liens vers d'autres pages.
GNOME a migré déjà pas mal de sa documentation sous forme de topiques, en langage Mallard. Au Desktop Summit il y a eu une conférence sur le sujet, et l'auteur en a fait un résumé sur son blog.
[^] # Re: À se demander…
Posté par swilmet . En réponse au journal Verne privé de système de fichiers au beurre. Évalué à 1.
Mais ce n'est pas le wiki de Btrfs ici, c'est un journal de Linuxfr.
[^] # Re: Noms longs ?
Posté par swilmet . En réponse au journal Petite^W Longue critique du livre Code Complete. Évalué à 4.
Oui, Python ou Ruby sont beaucoup plus pratique pour ça.
Mais si tu dois faire du C, tu n'as pas le choix…