jyes a écrit 943 commentaires

Autant les styles sont indispensables dans un traitement de texte, autant pour des diapos, qu'on essaye généralement de garder peu nombreux pour ne pas perdre l'auditoire, c'est moins grave.

Oui, enfin les diapos ça ne sert pas qu’aux commerciaux pour faire de boulettes-listes de fritures qui vendent du rêve. Quand tu prépares des supports de cours pour plus d’une dizaine de séances, ou pour un auditoire expert (oui, il en a qui n’arrêtent jamais les cours), avoir plusieurs centaines de diapos ça n’a plus rien d’exceptionnel. Ça n‘a rien non plus d’exceptionnel de vouloir réutiliser telle démonstration présentée dans tel cours, et de l’inclure dans tel support prévu pour une autre formation dans un autre contexte. Dans cette situation, les styles changent tout ! Ce n’est pas pour rien que LaTeX Beamer, malgré toute sa lourdeur et sa complexité, a encore une bonne base d’utilisateurs. Le masochisme ne fait pas tout.

Tout effacer te fait moins peur qu’une opération réversible ? C’est étrange. Bon c’est vrai qu’une fois que tu as une sauvegarde, btrfs-convert t’épargne juste le temps de la copie, ce qui n’est pas si long si tu ne dois le faire qu’une fois. Mais pour moi qui manque d’espace de stockage et qui ai une confiance un peu naïve en btrfs, btrfs-convert m’a bien aidé plusieurs fois.

Le paquet movie15, discuté en détail sur un site génial, fait des merveilles, et les vidéos sont lisibles avec PDF-Presenter-Console et même dans Evince depuis quelques temps. Je n’ai pas essayé avec Okular, mais ça marche probablement aussi.

Alors, qu’est-ce qui te retient ? Presque toutes mes présentations, faites avec Beamer, ont des vidéos.

les motorisations diesel, devraient juste être interdits.

Oui, et toutes être remplacées par des véhicules électriques dont la fabrication n’émet aucune pollution. C’est évident que pour polluer moins, il faut en permanence renouveler le parc automobile vers des nouvelles voitures qui émettent un peu moins au kilomètre marginal et balancer immédiatement tout ce qui a déjà commencé à amortir le coût environnemental de sa fabrication. On pourrait même faire des primes à la casse pour sauver l’industrie automobile la planète !

si le ifdef est dans le .h, c'est pour une raison…

La plus courante, c’est quand-même de ne pas tout péter quand ton .h est lui même inclus par un autre .h. Le #ifdef ressemble alors plus à un contournement malheureux qu’à une solution justifiée par une bonne raison. Dans l’exemple que tu donnes, tu peux bien mettre le #ifdef dans la déclaration du module, et il sera appliqué une bonne fois pour toutes, au lieu d’être redécouvert à chaque nouveau fichier .c(pp) qui utilise ton .h.

Personnellement, l’absence de module est l’une des principales choses qui me rend la programmation en C++ désagréable, les autres problème que j’avais avec ce langage s’étant bien améliorés avec C++17. Tant mieux si en 2020, C++ devient un langage aussi moderne que Fortran.

J'ai pas grand chose à apporter comme explications à ce sujet…

Il faut bien sauver les banques, puis l’aviation, et sauver l’emploi avec le CICE, soutenir l’industrie de pointe avec le CIR… ce n’est parce-qu’il n’y a pas d’argent magique, qu’on ne trouve pas des moyens pour en gaspiller.

J'en ai essayé d'autres, mais soit il y avait des dépendances (liquidprompt est en bash), soit ils ne m'apportaient rien de plus.

Comme j’en avais pris l’habitude avant que nohjan ne partage et fasse la pub de liquidprompt ici, je suis resté sur une solution avec dépendance : Powerline. Pas sûr que ça apporte quelque chose en plus, mais ça me convient bien et je l’avais déjà configuré d’une façon qui me satisfait.

J'ai dis que sans évaluation, il y en aura plus que sans.

J’aimerais une source sérieuse pour soutenir cette thèse. Mon expérience c’est que l’évaluation dans la recherche publique, notamment via la bibliométrie et les financements par projet, cause beaucoup de démotivation et convertit des chercheurs motivés en « tirent-au-flanc » (même si j’ai du mal avec ce qualificatif qui me parait inapproprié dans ce contexte, même quand appliqué aux pires éléments).

Il faudrait les 3 axes d'évaluation pour les enseignants chercheurs : recherche, formation, et vulgarisation.

Ou alors, pour que les enseignants-chercheurs puissent passer leur temps à toutes leurs missions sans introduire de biais ridicules et une course aux indicateurs idiots, plutôt que de rajouter une flopée d’axes d’évaluation, on pourrait aussi les évaluer un peu moins et les laisser bosser un peu plus. Parce-que bon, les “axes d’évaluation” c’est pas ce qui manque dans l’enseignement et la recherche (surtout la recherche en fait) et ça ne fait rien avancer.

Je suis absolument outré par la petite bande de scientistes auto-proclamés zététicien sceptiques qui "dunningent kruger" sans ménagement sur les réseaux sociaux.

Sur le seul réseau social que j’utilise, LinuxFr, je ne partage pas du tout ton ressenti. Le premier journal qu’on a eu sur l’épidémie de Covid était de très bonne facture et apparemment pas si nul vu l’actualité qui a suivi. Un certain nombre de ses successeurs aussi. Mais je ne peux que juger indirectement, ce n’est pas mon domaine. Par contre, dans mon domaine, je n’ai jamais lu de grosses absurdités sur LinuxFr. Enfin, si, mais sous forme de question dans les commentaires, donc de manière tout à fait bienvenue et qui laissait place à la correction.

Oui, d’ailleurs nos systèmes d’exploitation devraient forcer une perte de données tous les deux jours pour s’assurer qu’on sait restaurer les sauvegardes et on devrait refaire nos configs de Vim et d’Emacs tous les trois jours pour garantir qu’on sait bien les refaire.

Effectivement, on aurait très vite tous des recettes Ansible pour refaire nos réglages de manière automatique, et on survivrait à de tels choix en améliorant notre technique. Mais je ne suis pas d’accord avec « Plus quelques chose pose problème, plus il faut le faire fréquemment ». La démarche non-shadok consiste plutôt à limiter les problèmes. Automatiser la mise à jour des certificats est une excellente chose pour éviter les mauvaises surprises et règle bien des problèmes, mais ce n’est pas une raison pour rendre la vie plus dure à ceux qui ne font pas les choses aussi bien.

Comme sur les voitures finalement ! En plus la solution technique adoptée est plus élégante, plus simple et ne nécessite ni clé électronique ni ordinateur de bord. J’espère qu’un diçaïdeur de l’industrie automobile lira LinuxFr et y trouvera cette perle de sagesse.

Alors, non et non. Non, je n’utilises pas KDE, mais non les chaînes de plus d’un caractère ne fonctionnent pas chez moi, même en utilisant XIM dans un logiciel GTK.
Du coup, j’ai cherché l’origine du problème. C’est la variable d’environnement XMODIFIERS. En effet, chez moi, avec FCITX activé, elle est définie comme

XMODIFIERS=@im=fcitx

ce qui fait que la méthode de saisie XIM utilise en fait FCITX. Pour utiliser XIM et XIM seul dans un logiciel GTK, il faut donc redéfinir les deux variables

XMODIFIERS=@im=none
GTK_IM_MODULE=xim

Testé avec un logiciel Qt, je n’arrive à produire qu’un seul caractère, quelles que soient les variables d’environnement que je définis. Je n’utilise pas les compositions pour produire plus d’un caractère donc ça ne m’embête pas beaucoup, et je constate que c’est un fonctionnalité sympathique mais mal supportée.

Le plus simple avec Debian (ou Ubuntu), c’est de configurer la méthode de saisie à l’aide de l’outil « im-config ». Chez moi, il définit les variables d’environnement suivantes :
GTK_IM_MODULE=fcitx
QT4_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
CLUTTER_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
Il en manque peut-être chez vous pour certains logiciels ou certaines versions de Qt. Les réponses aux questions courantes sur le site de FCITX recensent les problèmes les plus fréquents et leurs solutions.

Je n’utilise pas FCITX pour écrire du mandarin. En fait, je ne pratique aucune langue qui utilise autre chose qu’un alphabet latin, donc je ne saurais pas me prononcer sur les points forts ou faibles des différentes méthodes de saisie pour cet usage. Personnellement, j’utilise FCITX pour saisir facilement des caractères mathématiques et grecs avec leurs codes LaTeX, et il fonctionne bien.

Il n'y a sans doute pas de solution miracle

Et est-ce vraiment nécessaire ? Pourquoi un même joueur qui voudrait essayer deux manières de jouer différentes avec deux personnages différents ne devrait pas le faire ? Surtout que les personnages évoluent en compétences, donc on peut prendre du plaisir à jouer des personnages très différents, qui suivent des voies différentes. Appliquer une limite de 1 perso par joueur dans un jeu de rôle (ou assimilé), ce n’est pas loin de n’autoriser le joueur à jouer qu’à un seul jeu sur son ordinateur (faudrait choisir entre Rolling ou SuperTuxKart ?)… c’est dommage, surtout pour un jeu qui semble offrir une telle richesse dans les manières de jouer !

Je n’y crois pas du tout, l’Alberta tourne au ralenti en ce moment à cause du prix bas du pétrole, mais a déjà les infrastructures pour répondre à la demande à un prix du pétrole un peu plus cher que maintenant, mais largement assez compétitif pour inhiber la transition énergétique vers d’autres ressources. C’est justement parce-que je ne crois pas à un impact suffisant sur le prix que je pense que tant qu’on attend une crise pétrolière économique, on se prépare mal à la crise climatique qui presse bien davantage.

Mais bon, pour le moment on en est à financer l’aviation pour sauver l’économie, c’est sûrement que l’écologie peut attendre un peu.

Comme tu le soulignes, s’il y a un pic, il concerne uniquement le pétrole « conventionnel », mais les réserves marines et dans les sables bitumineux canadiens et vénézuéliens nous assurent assez de pétrole et à un coût assez bas pour réchauffer notre planète de plusieurs dizaines de degrés. Je trouve donc la notion de « peak oil » dépassée et dangereuse car elle fait croire que l’épuisement des ressources pourrait piloter la transition vers d’autres sources d’énergie, alors que les ressources pétrolières sont bien trop abondantes et qu’il faut de tourner vers autre chose bien plus tôt, si l’on souhaite que la Terre reste habitable avant qu’on en ait exploité ne serait-ce que le quart.

À lire aujourd’hui des articles aux titres trompeurs sur un potentiel manque de pétrole en Europe, on ne trouvera demain que des articles pour nous dire que finalement non, mais que la teneur en CO₂ de notre atmosphère a encore augmentée. Je préfères lire aujourd’hui les articles sur le besoin de développer les alternatives aux énergies fossiles face au réchauffement climatique.

Un type avait fait un super journal sur le sujet. La conclusion mise à jour c’est que maintenant l’excellent FCITX fait tout bien et permet d’utiliser le fichier .XCompose et les tables de X.org / Freedesktop plutôt que les tables codées en dur et mal synchronisées entre elles de GTK, Qt, IBus et autres.

Si je fais la même opération avec LO, le document est cassé, le correspondant est furieux (car seul "word" et un bonne dose d'huile de coude est nécessaire à sa réparation).

Ouais, enfin des histoires de documents Word corrompus que seul LO arrive à sauver ça arrive souvent aussi, donc je ne m’aventurerai pas trop sur ce terrain pour comparer les suites logicielles. Je suis à nouveau surpris par ton commentaire car pour ce qui est de :
- schéma : j’ai l’expérience inverse, surtout dans des fichiers PPTX avec animations qu’OO rend de manière catastrophique, là où LO s’en sort mieux (mais rarement parfaitement aussi) ;
- une table, des colonnes : jamais constaté de soucis avec LO mais c’est peut-être mon cas d’utilisation qui me préservre de ces bogues ;
- du suivi des modifications : alors là je suis extrêmement surpris, car c’est la fonction centrale que j’utilise dans LO quand je travaille justement sur des documents avec des collègues qui utilisent MSO et le suivi de modifications me semble au contraire vraiment très bien fonctionner et bénéficier d’un très bon support d’import/export en OOXM par LO.

Bref, si on m'envoie un docx je peux l'ouvrir, le lire, le modifier (mais pas tout… pour l'instant) et le renvoyer sans que mon correspondant ne sache quel logiciel j'ai utilisé.

Moi non plus je n’informe pas mes correspondants des logiciels que j’utilise pour modifier leurs documents et je n’ai jamais eu de retour de leur part pour me dire que je leur avais cassé quoi que ce soit¹, pourtant c’est une part importante de mon travail que de modifier de tels documents. À l’inverse, j’ai eu de moins bonnes expériences avec OO qui parfois n’ouvre pas du tout des documents qu’on m’envoie.

le temps à réparer les erreurs de LO, c'est du temps perdu pour moi.

Comme pour tous le monde sauf les devs de LO. Sauf que ce temps est comparable à celui passé à résoudre des incompatibilités entre versions de MSO et des problèmes dus aux polices indisponibles sur certains ordinateurs, et n’est pas un défaut de LO qui je sens beaucoup peser.

Le « .Xcompose » est défini par chaque utilisateur et sa syntaxe est beaucoup moins absconse.

Par ailleurs, il n’y a pas forcément besoin de toucher à « /usr/share/X11 », ça c’est une solution proposée dans le journal si l’on ne sait pas faire autrement, mais les distributions peuvent proposer des outils plus simples (fichier de configuration « /etc/default/keyboard » et paquet « keyboard-configuration » de Debian par exemple).

Par contre, il ne supporte celles que j’ai définies dans .XCompose que si j’affecte avant la variable GTK_IM_MODULE=xim.

Ça c’est normal. Si tu n’utilises pas la « Méthode de saisie X » (XIM) et que tu as une touche « Compose », les compositions disponibles sont codées en dur dans GTK. Il faut passer par XIM pour que le fichier « .XCompose » serve à quelque-chose.

Chez moi la composition marche aussi avec “Chromium 83.0.4103.116 built on Debian 10.4, running on Debian 10.4” (testé avec et sans Fcitx activé pour utiliser XIM directement). Avec comme clavier :

$ setxkbmap -print
xkb_keymap {
    xkb_keycodes  { include "evdev+aliases(azerty)" };
    xkb_types     { include "complete"  };
    xkb_compat    { include "complete"  };
    xkb_symbols   { include "pc+fr+inet(evdev)+level3(ralt_switch)+compose(rctrl)+terminate(ctrl_alt_bksp)" };
    xkb_geometry  { include "pc(pc105)" };
};

c'est du ressors de la boite d'imposer les format

Presque d’accord, mais en pratique, beaucoup de sociétés ne travaillent pas seules et les problèmes surviennent généralement quand elle doivent échanger des documents avec l’extérieur. De fait la position dominante de MS et son très mauvais support d’OpenDocument font d’OOXML un choix, parce-que si une société fait le choix sain d’utiliser OpenDocument, presque toutes les autres sociétés se comporteront comme le windowsien décrit ci-dessus : « Ils en ont rien à battre et considèrent que les formats que eux utilisent doivent être utilisés par le reste du monde ».

Grace à OnlyOffice je peux survivre sous Linux au bureau et échanger des documents avec mes collègues et clients utilisant Office sans tout casser dans la mise en page dès que j'ouvre un fichier.

Je lis ça régulièrement ici sur LinuxFr, et à chaque fois, je suis très surpris. OnlyOffice est logiciel intéressant notamment comme suite bureautique en ligne et pour son intégration possible dans Nextcloud, mais sa compatibilité avec MS Office ne me semble pas du tout à la hauteur de celle de LibreOffice. J’utilise au quotidien OnlyOffice et LibreOffice sur mon ordinateur de travail pour échanger des fichiers au format OOXML avec des collègues. Je n’ai pas longtemps gardé OnlyOffice par défaut car en pratique son support d’OOXML (en tout cas de la variante utilisée par MS) me semble bien moins bon que l’import/export opéré par LibreOffice. Avec OnlyOffice, pas de vidéo dans les diapos, pas de macros dans les tableurs, pas de mise en page complexe dans le traitement de texte, alors que LibreOffice ne s’en sort pas si mal sur ces points même si ce n’est pas parfait. Mon expérience est carrément contraire à la tienne !

Alors qu’une part important de mon boulot consiste à travailler à plusieurs sur des documents produits par la suite MS Office, c’est grâce à LibreOffice que je peux survivre sous Linux, avec OnlyOffice comme solution de repli (souvent décevante en plus) pour les cas problématiques avec LO. Utilises-tu une version relativement à jour de LibreOffice ? J’utilise celle de Debian backports et la lecture/écriture au format OOXML est souvent très satisfaisante.

[Ce commentaire est une réponse au journal, pas au commentaire ci-dessus, je me suis trompé de bouton « répondre »]

Malheureusement, Ctrl+Maj+u n’est disponible qu’avec une méthode de saisie « moderne », et ces dernières ne prennent pas en charge le fichier .XCompose, donc il faut choisir entre les deux. […] Pour que .XCompose soit pris en charge, il est nécessaire de choisir la méthode de saisie XIM

Moi aussi, je croyais la même chose, puis j’ai découvert Fcitx qui peu utiliser XIM quand il n’est pas dans un de ses modes saisies à lui et combine ainsi le meilleur des deux mondes. Une touche Compose configurable via le fichier .XCompose et des modules de saisie complémentaires pour des symboles plus variés (j’utilise surtout le module Table LaTeX pour saisir des caractères grecs et mathématiques avec leur code LaTeX).

Après avoir galéré avec IBus, Scim, UIM, etc, je dois avouer que Fcitx a été une bouffée d’air frais.

Note : je ne sais pas pourquoi certains logiciels le désactivent (comme Firefox et Chromium), mais les menus GTK et Qt des zones de saisie permettent normalement de changer à la volée la méthode d’entrée avec un simple clic. Ce n’est pas aussi pratique que d’avoir une méthode d’entrée qui utilise XIM directement mais ça permet de sauver les meubles si l’on est contraint d’utiliser une méthode qui vient avec sa propre implémentation boguée de la touche Compose (c’est-à-dire presque toutes : IBus, Scim, UIM…).