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.
Je ne l'ai pas lu, mais à la fin du chapitre sur le refactoring dans Code Complete, c'est la seule ressource additionnelle qui est donnée, avec ce commentaire :
This is the definitive guide to refactoring. It contains detailed discussions of many of the specific refactorings summarized in this chapter, as well as a handful of other refactorings not summarized here. Fowler provides numerous code samples to illustrate how each refactoring is performed step by step.
Mais il faut savoir que la 2e édition de Code Complete est sortie en 2004, donc il se peut qu'un autre livre plus récent, et peut-être meilleur, est sorti.
Voici ce qui est dit dans le livre, qui s'applique tant pour les for, que pour les while :
Si un index de boucle doit être utilisé en-dehors de la boucle (parfois bien après), c'est préférable de lui donner un nom long.
Si une boucle est assez longue, il est facile d'oublier à quoi correspond le i ou le j (donc il faut souvent revenir en haut de la boucle pour voir à quoi elle correspond). Du code est souvent modifié, étendu, et copié dans d'autres programmes, donc beaucoup de programmeurs expérimentés évitent complètement des noms comme i.
Une des raisons pour lesquelles les boucles s'allongent est qu'elles sont imbriquées. Pour améliorer la lisibilité, il vaut mieux mettre des noms longs. Ça permet d'éviter de confondre i et j, et ça rend certaines lignes plus informatives (comme je l'ai expliqué dans le journal).
Si vous devez vraiment utiliser i, j et k, faites le uniquement pour des boucles simples (donc qui ne sont pas imbriquées, et qui ne sont pas très longues, et dont l'index n'est pas utilisé en-dehors). Mais pour éviter tout problème, c'est plus simple de se donner une règle où on n'utilise pas du tout les i, j et k.
Voilà, pour moi la meilleure raison est la première, que j'avais déjà expliqué dans le commentaire juste au-dessus.
En ayant lu The Pragmatic Programmer, tu risques de connaitre déjà beaucoup de chose en lisant Code Complete. Mais Code Complete parle de plus de sujets.
Beautiful Code est sorti en 2007, donc c'est normal que Code Complete (2e édition en 2004) ne le référence pas, mais ça a l'air intéressant. Il y a aussi Programmers at Work, qui est plus ancien.
Oui, c'est un des conseils qui est assez controversé.
Ce qui gêne plus, c'est quand le i ou le j est utilisé en-dehors de la boucle, pour retenir par exemple le dernier index valide ou qqch du genre. Dans ce cas il vaut carrément mieux créer une autre variable retenant cet index, avec un nom qui permet de savoir de quoi il s'agit.
Ah ben tant mieux s'il est bien écrit, tu fais bien de le dire.
Mais personnellement, en informatique je préfère lire de l'anglais. J'ai donné une raison (les termes techniques qui ne sonnent pas bien en français). Mais c'est aussi un bon entrainement, on apprend du vocabulaire, etc.
Aussi, le dernier paragraphe c'était histoire de troller un peu vers la fin :) Il fallait bien que quelqu'un ne soit pas du même avis.
Dans le livre il y a dans les marges pas mal de références vers d'autres sections du livre, mais les références sont trop vagues (il faut chercher une sous-sous-section parmi une quinzaine de pages parfois…), il faudrait des numéros de pages.
Et aussi, le texte est en « fer à gauche » au lieu d'être justifié. Mais bon on s'y fait.
Sinon, hors-sujet, mais je dois pas être fait pour le marketing : je suis arrivé à écrire « Bref, à déconseiller. » tout à la fin, alors que je n'ai montré que des points positifs du livre :)
Si tu n'aimes pas le titre du thread^W fil, rien ne t'empêchais de la changer dans ton propre commentaire.
C'est d'ailleurs une fonctionnalité très peu utilisée sur Linuxfr je trouve, et qui serait bien pratique, pcq parfois certains fils deviennent monstrueusement long, et ça part dans tous les sens.
Si en plus tu organises ta façon de travailler correctement, c'est très correct.
C'est ça que je n'aime pas avec GNOME 3, c'est qu'il y a beaucoup moins de « façon de travailler correctement » qu'avec GNOME 2. Avec GNOME 2 c'était beaucoup plus flexible de ce côté-là.
Par exemple, pour ma part, j'aime bien avoir plusieurs fenêtres différentes maximisées sur le même espace de travail. Avec GNOME 2, en un seul clic je vais sur la fenêtre de mon choix. Avec GNOME 3, peut importe la méthode, ça demande plus d'étapes.
Ma mère et ma petite sœur n'ont jamais utilisé plus d'un espace de travail, bien que je leur ai déjà expliqué plusieurs fois, que c'est vraiment pratique, etc. Rien à faire. Avec GNOME 3, si tu n'utilises qu'un seul espace de travail, c'est l'enfer, là où avec GNOME 2 c'est encore gérable.
J'avoue que je considère assez fortement de rester sur gnome-panel+metacity plutôt que de passer à gnome-shell+mutter. Et si un jour ça n'est plus maintenu je créerais un fork sans hésiter
De nouveau, si le mode fallback te convient bien, pourquoi créer un fork ? Il « suffit » de continuer à maintenir gnome-panel et metacity, quand les développeurs décideront de les abandonner.
While you are at it, could you also fork gnome, and support a gnome-2 environment?
Ce qu'il faudrait plutôt, c'est régler toutes les régressions de gnome-panel et de continuer à le maintenir¹. Je sais qu'il y a certaines applets manquantes, par exemple (mais certaines applets sont externes au projet GNOME, donc pour ça on ne peut pas leur en vouloir). Je ne sais pas où en est GNOME 3.1 à ce niveau-là, mais la version 3.0 apportait quand même pas mal d'améliorations de gnome-panel par rapport à GNOME 2, notamment le placement des applets (qui partait souvent en c... cacahouète avec GNOME 2).
Bon un autre problème, même avec le mode de fallback (gnome-panel au lieu de gnome-shell), c'est qu'il manque énormément d'options de configuration. gnome-tweak-tool règle partiellement ce problème, mais ça devrait aller mieux avec GNOME 3.2.
Et j'oublie aussi le passage à GTK+ 3 où les marges internes des widgets sont devenues trop grandes.
Donc pour moi ça ne sert pas à grand chose de forker GNOME 2. Mais c'est clair que le mode fallback ne devrait pas avoir de régressions.
¹ J'avais lu que les développeurs de GNOME comptent encore maintenir gnome-panel pendant encore quelques temps, mais pas indéfiniment.
[^] # Re: Précisions
Posté par Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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 Sébastien Wilmet (site web personnel, Mastodon) . 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…
[^] # Re: -
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Petite^W Longue critique du livre Code Complete. Évalué à 3.
Je ne l'ai pas lu, mais à la fin du chapitre sur le refactoring dans Code Complete, c'est la seule ressource additionnelle qui est donnée, avec ce commentaire :
Mais il faut savoir que la 2e édition de Code Complete est sortie en 2004, donc il se peut qu'un autre livre plus récent, et peut-être meilleur, est sorti.
[^] # Re: Noms longs ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Petite^W Longue critique du livre Code Complete. Évalué à 2.
Voici ce qui est dit dans le livre, qui s'applique tant pour les for, que pour les while :
Si un index de boucle doit être utilisé en-dehors de la boucle (parfois bien après), c'est préférable de lui donner un nom long.
Si une boucle est assez longue, il est facile d'oublier à quoi correspond le i ou le j (donc il faut souvent revenir en haut de la boucle pour voir à quoi elle correspond). Du code est souvent modifié, étendu, et copié dans d'autres programmes, donc beaucoup de programmeurs expérimentés évitent complètement des noms comme i.
Une des raisons pour lesquelles les boucles s'allongent est qu'elles sont imbriquées. Pour améliorer la lisibilité, il vaut mieux mettre des noms longs. Ça permet d'éviter de confondre i et j, et ça rend certaines lignes plus informatives (comme je l'ai expliqué dans le journal).
Si vous devez vraiment utiliser i, j et k, faites le uniquement pour des boucles simples (donc qui ne sont pas imbriquées, et qui ne sont pas très longues, et dont l'index n'est pas utilisé en-dehors). Mais pour éviter tout problème, c'est plus simple de se donner une règle où on n'utilise pas du tout les i, j et k.
Voilà, pour moi la meilleure raison est la première, que j'avais déjà expliqué dans le commentaire juste au-dessus.
[^] # Re: Sur ma liste
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Petite^W Longue critique du livre Code Complete. Évalué à 2.
En ayant lu The Pragmatic Programmer, tu risques de connaitre déjà beaucoup de chose en lisant Code Complete. Mais Code Complete parle de plus de sujets.
Beautiful Code est sorti en 2007, donc c'est normal que Code Complete (2e édition en 2004) ne le référence pas, mais ça a l'air intéressant. Il y a aussi Programmers at Work, qui est plus ancien.
[^] # Re: Noms longs ?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Petite^W Longue critique du livre Code Complete. Évalué à 4.
Oui, c'est un des conseils qui est assez controversé.
Ce qui gêne plus, c'est quand le i ou le j est utilisé en-dehors de la boucle, pour retenir par exemple le dernier index valide ou qqch du genre. Dans ce cas il vaut carrément mieux créer une autre variable retenant cet index, avec un nom qui permet de savoir de quoi il s'agit.
[^] # Re: FR
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Petite^W Longue critique du livre Code Complete. Évalué à 5.
Dans le lien que tu donnes, il y a un commentaire contradictoire :
[^] # Re: FR
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Petite^W Longue critique du livre Code Complete. Évalué à 5.
Ah ben tant mieux s'il est bien écrit, tu fais bien de le dire.
Mais personnellement, en informatique je préfère lire de l'anglais. J'ai donné une raison (les termes techniques qui ne sonnent pas bien en français). Mais c'est aussi un bon entrainement, on apprend du vocabulaire, etc.
Aussi, le dernier paragraphe c'était histoire de troller un peu vers la fin :) Il fallait bien que quelqu'un ne soit pas du même avis.
# Les points négatifs
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Petite^W Longue critique du livre Code Complete. Évalué à 4.
Oups. J'ai oublié de parler des points négatifs.
Dans le livre il y a dans les marges pas mal de références vers d'autres sections du livre, mais les références sont trop vagues (il faut chercher une sous-sous-section parmi une quinzaine de pages parfois…), il faudrait des numéros de pages.
Et aussi, le texte est en « fer à gauche » au lieu d'être justifié. Mais bon on s'y fait.
Sinon, hors-sujet, mais je dois pas être fait pour le marketing : je suis arrivé à écrire « Bref, à déconseiller. » tout à la fin, alors que je n'ai montré que des points positifs du livre :)
[^] # Oh, un autre titre !
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Bonnes connaissances en environnements Linus. Évalué à 5.
Si tu n'aimes pas le titre du thread^W fil, rien ne t'empêchais de la changer dans ton propre commentaire.
C'est d'ailleurs une fonctionnalité très peu utilisée sur Linuxfr je trouve, et qui serait bien pratique, pcq parfois certains fils deviennent monstrueusement long, et ça part dans tous les sens.
[^] # Re: Troll mode (just for fun, won’t be big and professional like pBpG)
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Bonnes connaissances en environnements Linus. Évalué à 3.
C'est ça que je n'aime pas avec GNOME 3, c'est qu'il y a beaucoup moins de « façon de travailler correctement » qu'avec GNOME 2. Avec GNOME 2 c'était beaucoup plus flexible de ce côté-là.
Par exemple, pour ma part, j'aime bien avoir plusieurs fenêtres différentes maximisées sur le même espace de travail. Avec GNOME 2, en un seul clic je vais sur la fenêtre de mon choix. Avec GNOME 3, peut importe la méthode, ça demande plus d'étapes.
Ma mère et ma petite sœur n'ont jamais utilisé plus d'un espace de travail, bien que je leur ai déjà expliqué plusieurs fois, que c'est vraiment pratique, etc. Rien à faire. Avec GNOME 3, si tu n'utilises qu'un seul espace de travail, c'est l'enfer, là où avec GNOME 2 c'est encore gérable.
[^] # Re: Troll mode (just for fun, won’t be big and professional like pBpG)
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Bonnes connaissances en environnements Linus. Évalué à 2.
De nouveau, si le mode fallback te convient bien, pourquoi créer un fork ? Il « suffit » de continuer à maintenir gnome-panel et metacity, quand les développeurs décideront de les abandonner.
[^] # Re: Troll mode (just for fun, won’t be big and professional like pBpG)
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Bonnes connaissances en environnements Linus. Évalué à 4.
Commentaire de Linus :
Ce qu'il faudrait plutôt, c'est régler toutes les régressions de gnome-panel et de continuer à le maintenir¹. Je sais qu'il y a certaines applets manquantes, par exemple (mais certaines applets sont externes au projet GNOME, donc pour ça on ne peut pas leur en vouloir). Je ne sais pas où en est GNOME 3.1 à ce niveau-là, mais la version 3.0 apportait quand même pas mal d'améliorations de gnome-panel par rapport à GNOME 2, notamment le placement des applets (qui partait souvent en c... cacahouète avec GNOME 2).
Bon un autre problème, même avec le mode de fallback (gnome-panel au lieu de gnome-shell), c'est qu'il manque énormément d'options de configuration. gnome-tweak-tool règle partiellement ce problème, mais ça devrait aller mieux avec GNOME 3.2.
Et j'oublie aussi le passage à GTK+ 3 où les marges internes des widgets sont devenues trop grandes.
Donc pour moi ça ne sert pas à grand chose de forker GNOME 2. Mais c'est clair que le mode fallback ne devrait pas avoir de régressions.
¹ J'avais lu que les développeurs de GNOME comptent encore maintenir gnome-panel pendant encore quelques temps, mais pas indéfiniment.