Journal Qu’on pose

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
36
14
juil.
2020

L’utilisation de Ctrl+Maj+u pour produire un caractère Unicode a été abordée ici.

J’ai failli répondre en commentaire, mais je me suis dit que ce qui suit pouvait être d’intérêt assez général pour un journal.

Nous utilisons un système de type Unix. Nous disposons donc de moyens plus civilisés pour produire des caractères que de retenir par cœur leur numéro Unicode.

Avec le fichier .XCompose (à créer à la racine du répertoire utilisateur, mais lisez les remarques en fin de journal avant), on peut choisir un moyen mnémotechnique de produire des caractères. Exemple :

<Multi_key> <colon> <parenright> : "☺" U263A # smiley

Soit Compose : ) pour produire un smiley. C’est quand même plus facile que de retenir 263A…

colon, désigne en effet les deux points et parenright la parenthèse fermante. Ces noms symboliques sont définis dans /usr/include/X11/keysymdef.h, pour peu qu’on ait installé le paquet qui le contient. U263A est là surtout à titre indicatif puisque la chaîne entre guillemets suffit à définir ce qui est produit. Mais il pourrait la remplacer.

Multi_key, désigne la touche Compose. Pour en disposer, il faut l’affecter quelque part sur le clavier. Les réglages clavier des environnements de bureau évolués le proposent (c’est aussi dans les options fournis par Xkb, si on définit le clavier « manuellement » dans /etc/X11/xorg.conf.d), mais on peut à la rigueur définir des règles à partir de n’importe quelle touche morte, pour peu qu’on évite de recouvrir des règles existantes.

Exemple en utilisant l’accent circonflexe mort :

<dead_circumflex> <colon> <parenright> : "☺" U263A # smiley

Mais l’intérêt supplémentaire du fichier .XCompose est qu’il ne permet pas seulement de produire des caractères, mais éventuellement des chaînes de caractères. Exemple :

<Multi_key> <e> <s> : "Veuillez agréer, Madame, Monsieur, l’expression de mes sincères salutations,"

C’est tout de même moins lourd quand on a que trois touches à taper !

Beaucoup de règles de composition sont prédéfinies dans /usr/share/X11/locale/en_US.UTF-8/Compose (c’est le fichier pour les États-Unis, mais les locales de la plupart des langues à caractères latins l’utilisent aussi) et sont donc utilisables directement, sans avoir à utiliser de fichier .XCompose. Il y en a peut‐être déjà une qui produit le caractère dont vous avez besoin (la règle avec Compose pour le smiley est déjà dedans ! mais aussi les règles de composition basiques, comme ˆ e → ê).

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.

À mon sens, les caractères dont on a besoin couramment doivent être accessibles directement sur la disposition de clavier ou à défaut par composition. Sinon, il faut changer de disposition, l’adapter ou au pire compléter les règles de composition. Et pour ceux dont j’ai rarement besoin, je n’arriverais pas à retenir le numéro Unicode, donc Ctrl+shift+u ne me manque pas vraiment.

Cela dit, les règles de composition de base sont reprises partiellement par les méthodes de saisie « modernes ». Donc si le caractère dons vous avez besoin est pris en charge par /usr/share/X11/locale/en_US.UTF-8/Compose, vous pouvez toujours essayer, même si vous utilisez une de ces méthodes de saisie.

Pour que .XCompose soit pris en charge, il est nécessaire de choisir la méthode de saisie XIM (ou pas de méthode de saisie) au niveau des réglages clavier de l’environnement graphique (désinstaller ibus et les méthodes de saisies est aussi une solution) et éventuellement d’insister pour certaines applications en mettant par exemple pour celles basées sur GTK dans le fichier .xprofile (ou équivalent pris en charge par l’environnement graphique) :

GTK_IM_MODULE=xim
export GTK_IM_MODULE

IMPORTANT : tout fichier .XCompose doit commencer par la ligne include "%L" pour inclure les règles de composition de la locale, sinon on perd même les plus basiques (comme ˆ e → ê), c’est gênant.

  • # Apostrophe

    Posté par  (site web personnel) . Évalué à 2.

    L'apostrophe de ton titre est faite avec compose?

    • [^] # Disposition

      Posté par  (site web personnel) . Évalué à 4.

      Non, avec ma disposition (dérivée de la disposition Bépo), en accès direct.

      Mais tu l’as aussi sur la disposition Bépo (en accès direct sur la dernière version, disponible sous le nom de « Français (BÉPO, AFNOR) » dans les réglages clavier des distributions récentes), en accès direct sur l’Azerty AFNOR (disponible aussi sur les distributions récentes sous le nom de « Français (AZERTY, AFNOR) ») et en AltGr+g sur l’Azerty OSS (appelée « Français (variante) » dans les réglages clavier ; si l’installateur de ta distribution n’est pas trop nul, c’est la version qu’il t’a proposée à l’installation, essaie de taper AltGr+g).

      Bon, si tu es attaché à ce que les touches de ton clavier produisent les caractères qui sont marqués dessus, tu préféreras sans doute t’en tenir à l’Azerty OSS…

      Prendre une bonne disposition : beop.free.fr

      • [^] # Re: Disposition

        Posté par  (site web personnel) . Évalué à 2.

        Ah je ne dois pas avoir la dernière version de BÉPO alors car je suis obligé de faire alt gr + ,

        • [^] # Nouvelle version de Bépo

          Posté par  (site web personnel) . Évalué à 3.

          Il y a eu des changements entre la version 1.0 de la disposition Bépo, historiquement intégrée à Xkb, et la 1.1, fournie à l’AFNOR pour faire partie de la norme.

          Le plus important est l’échange de l’apostrophe ASCII avec l’apostrophe typographique (pas sûr que les informaticiens apprécieront…).

          Ah je ne dois pas avoir la dernière version de BÉPO alors car je suis obligé de faire alt gr + ,

          Tu l’as peut-être sur ton système, s’il est récent (pas CentOS ou Debian stable…). Mais tu n’y passeras pas automatiquement : sous Xkb, elle a un nouveau nom, « bepo_afnor » pour le fichier de configuration de X.org, et « Français (BEPO, AFNOR) » depuis les paramètres de clavier des environnements graphiques.

          Prendre une bonne disposition : beop.free.fr

          • [^] # Re: Nouvelle version de Bépo

            Posté par  . Évalué à 3.

            Mais tu n’y passeras pas automatiquement

            Pas pour l'instant mais ça risque fort d'arriver. Car à moins que Xorg accepte de laisser immuablement la version 1.0 en fr bepo, les changements effectués pour la 1.1 (= la version AFNOR) et les suivantes seront intégrés tôt ou tard en remplacement.
            En réalité, parmi les trois variantes proposées actuellement (si Latin9 est toujours bien présente), la seule qui n'est pas susceptible de changer d'un iota c'est bepo_afnor.

            • [^] # Re: Nouvelle version de Bépo

              Posté par  (site web personnel) . Évalué à 2.

              Mais tu n’y passeras pas automatiquement

              Pas pour l'instant mais ça risque fort d'arriver. Car à moins que Xorg accepte de laisser immuablement la version 1.0 en fr bepo, les changements effectués pour la 1.1 (= la version AFNOR) et les suivantes seront intégrés tôt ou tard en remplacement.

              Est‐ce juste un ressenti, ou as‐tu des éléments allant dans ce sens ?

              As-tu vu le nombre de variantes de l’Azerty français définies dans le fichier /usr/share/X11/xkb/symbols/fr ?
              L’une des deux dernières ajoutées étant la reproduction fidèle de l’Azerty de Windows dans toute sa médiocrité (cela dit, ça peut éviter des surprises aux habitués de Windows, notamment pour taper un mot de passe en Verr. Maj. qui n’est pas réellement ce qu’ils pensent).

              Pour moi, seul l’Azerty OSS fait sens, hormis l’Azerty AFNOR du fait de la norme, même si c’est peut-être la disposition la moins utilisée (le fait qu’il semble n’y avoir qu’un seul clavier du commerce qui suive la norme n’aide pas).

              Ça vaudrait peut-être le coup de faire évoluer l’Azerty OSS en reprenant les caractères proposés par l’Azerty AFNOR (bon, ça ferait une version de plus de l’Azerty). Ça en ferait un remplacement intéressant pour les claviers Azerty existants, qui resterait pertinent quand la norme sera enterrée faute de volonté politique (comme auparavant la NF XP E55-060 et la NF E55-070).

              Prendre une bonne disposition : beop.free.fr

              • [^] # Re: Nouvelle version de Bépo

                Posté par  . Évalué à 2.

                Est‐ce juste un ressenti, ou as‐tu des éléments allant dans ce sens ?

                Les release candidate précédentes de la 1.0 ont été remplacées dans les deux fichiers historiques donc sauf changement de politique (celle de xkb ou de bépo) l'entrée fr bepo est enclin à évoluer vers la 1.1 ou directement vers une 1.2

                De plus, si la 1.0 reste dans Xorg, la garder à l'emplacement fr-bepo posera aussi toute sorte de problèmes de màj des tutos et des scripts. Rien que sur les docs officielles de la distrib (déjà pas à jour alors que ça fait presque 10 mois que bepo_afnor est inclus dans Xorg, ça non plus ça n'aide pas) ce sera bien coton de corriger un tel changement de nomenclature, et ce sans même prendre en compte les nombreuses sources externes (docs de distibutions, blogs, forums, articles, etc.) plus compliquées à lister et modifier.

                Donc voilà d'un point de vue historique ou pratique, fr bepo a très peu de chances de rester en 1.0 et la seule manière raisonnable de la garder dans Xorg serait de créer une nouvelle entrée du genre fr bepo-old.

                • [^] # Re: Nouvelle version de Bépo

                  Posté par  (site web personnel) . Évalué à 1. Dernière modification le 16 juillet 2020 à 12:20.

                  Les release candidate précédentes de la 1.0 ont été remplacées dans les deux fichiers historiques

                  Parles‐tu de fichiers d’Xkb ou du site de la disposition Bépo ?

                  Du côté d’Xkb, ça ne semble pas changer pour l’instant.

                  À ma connaissance, les membres du projet Bépo ne sont pas en relation avec les développeurs d’Xkb, donc ceux‐ci feront ce qu’ils estiment le mieux de leur point de vue.

                  La question que je me pose d’abord est de savoir si les règles de composition étendues de la nouvelle version de la disposition Bépo et spécifiques à elle finiront par être prise en charge par Xkb. Parce que pour l’instant, ce n’est pas le cas. Voir les UFDDx dans la section bepo_afnor du fichier symbols/fr, qui sont des caractères utilisés temporairement en attendant qu’un symbole de composition soit défini.

                  J’ai l’impression que l’évolution de l’implémentation de la norme AFNOR suis l’intérêt que cette dernière suscite et qui est bien retombé. La nouvelle disposition Azerty n’est pas plus avancée, elle contient des vides à la place des symboles de composition manquants.

                  Prendre une bonne disposition : beop.free.fr

                  • [^] # Re: Nouvelle version de Bépo

                    Posté par  . Évalué à 2.

                    Parles‐tu de fichiers d’Xkb ou du site de la disposition Bépo ?
                    Du côté d’Xkb, ça ne semble pas changer pour l’instant.

                    Je parle de xkb, l'ajout de bépo y a été fait en 2006-2007 puis il y a eu mise à jour jusque la 1.0

                    À ma connaissance, les membres du projet Bépo ne sont pas en relation avec les développeurs d’Xkb, donc ceux‐ci feront ce qu’ils estiment le mieux de leur point de vue.

                    C'est encore aux premiers de décider puis de proposer le changement aux devs de xkb, exactement comme pour l'ajout de bepo_afnor ou des précédentes MÀJ.

                    La question que je me pose d’abord est de savoir si les règles de composition étendues de la nouvelle version de la disposition Bépo et spécifiques à elle finiront par être prise en charge par Xkb.

                    Bof. Il y a quelques années on devait déjà éditer .XCompose pour la touche morte du grec monotonique, ça ne fait pas vraiment une grosse différence. Le bout de code à dupliquer est plus gros, c'est tout.
                    Perso pour la 1.1 j'ai déjà dû éditer pour remettre le Dollar et le Bath à leur ancienne place sur la couche monétaire au lieu du Spesmilo et du bitecoin imposés par la norme. (et là encore, le wiki est toujours pas à jour)

                    J’ai l’impression que l’évolution de l’implémentation de la norme AFNOR suis l’intérêt que cette dernière suscite et qui est bien retombé.

                    Je sais pas comment ça fonctionne du côté azerty, mais de l'autre côté faudrait déjà finir la doc au moins avant la prochaine Debian stable (c'est déjà trop tard pour Centos8).

    • [^] # Re: Apostrophe

      Posté par  . Évalué à 1.

      Alt-gr + Shift + G sur fr-oss.

      • [^] # Re: Apostrophe

        Posté par  (site web personnel) . Évalué à 2.

        Non, pas Shift, juste AltGr. Extrait de /usr/share/X11/xkb/symbols/fr :

        partial alphanumeric_keys
xkb_symbols "oss" {
[…]
    key <AC05>  { [                g,                G, rightsinglequotemark,                   yen ] }; // g G ’ ¥

        Prendre une bonne disposition : beop.free.fr

        • [^] # Re: Apostrophe

          Posté par  . Évalué à 2.

          Ouais, je me suis rendu compte de mon erreur trop tard pour corriger. Vous pouvez moinsser.

    • [^] # Re: Apostrophe

      Posté par  . Évalué à 4.

      Puisqu'on parle de la touche compose, soulignons qu'on peut également avoir cette apostrophe courbe avec Compose-'-> (soit l'apostrophe ASCII suivie de > pour RIGHT SINGLE QUOTATION MARK (et de < pour LEFT SINGLE QUOTATION MARK). On peut avoir également les guillemets anglais avec Compose-"-< ou >.

  • # top!

    Posté par  . Évalué à 3.

    Je viens de rajouter un non-breaking space dans mon .Xcompose: 

       include "%L"

   <Multi_key> <n> <b> <space> : nobreakspace # NON-BREAKING SPACE

    Sous X11/awesomewm sans variable d'environnement GTK_IM_MODULE, cela fonctionne correctement dans un terminal urxvt et vim, mais pas dans cette boite de saisie de texte sous firefox ou dans gvim, alors que les autres combinaisons fonctionnent correctement.
    Par contre en rajoutant export GTK_IM_MODULE=xim, cela fonctionne dans gvim , mais toujours pas dans firefox !

     
    D'autre part, existe-t-il un équivalent pour une console en environnement non graphique ?

     

    • [^] # Re: top!

      Posté par  (site web personnel) . Évalué à 1.

      Par contre en rajoutant export GTK_IM_MODULE=xim, cela fonctionne dans gvim , mais toujours pas dans firefox !

      Deux pistes :

      • les logiciels prennent en compte les règles de composition existantes au moment de leur lancement, donc si tu viens de créer le fichier, il convient de relancer Firefox ;
      • pour avoir un effet, la variable GTK_IM_MODULE doit être définie dans l’environnement de lancement des logiciels, qu’est-ce que ça fait si tu lances Firefox depuis un terminal où tu viens de définir la variable ?

      D'autre part, existe-t-il un équivalent pour une console en environnement non graphique ?

      Je ne sais pas, je n’ai pas un usage tel des consoles texte que j’aie ressenti le besoin de disposer des mêmes règles de composition dessus…

      Prendre une bonne disposition : beop.free.fr

      • [^] # Compose en console

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 14 juillet 2020 à 14:17.

        D'autre part, existe-t-il un équivalent pour une console en environnement non graphique ?

        Je ne sais pas, je n’ai pas un usage tel des consoles texte que j’aie ressenti le besoin de disposer des mêmes règles de composition dessus…

        Plus précisément : la touche Compose est supportée dessus (par exemple, Compose ' e donne é)… à condition d’en disposer (c’est le cas avec ma disposition).

        Sur une distribution où la disposition de la console est créée dynamiquement à partir de celle d’X.org (Debian, Ubuntu et leurs dérivées), il faudrait voir si les options permettant l’ajout d’une touche Compose sont prises en compte (pour les connaître : grep -i compose /usr/share/X11/xkb/rules/evdev.lst).

        Mais les règles de composition ne sont pas les mêmes que sous X.org (la règle pour le smiley n’existe pas…).

        Ce que je ne sais pas, c’est si on peut étendre ces règles de composition ni comment.

        Prendre une bonne disposition : beop.free.fr

    • [^] # Re: top!

      Posté par  . Évalué à 4.

      Je viens de rajouter un non-breaking space dans mon .Xcompose:

      Pas besoin de le rajouter, on peut déjà l'obtenir nativement en faisant Compose-space-space.
      Du coup, c'est dispo également sur d'autres machines (linux), quand tu es en déplacement.

      • [^] # Re: top!

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 14 juillet 2020 à 14:38.

        Effectivement, ça vaut toujours le coup de faire un grep du caractère qu’on veut obtenir sur /usr/share/X11/locale/en_US.UTF-8/Compose.

        Ce qui est triste, c’est que les claviers PC n’aient pas la touche Compose d’origine. Et la mode actuelle de suppression de touches (Windows droite, Menu, Arrêt défilement…) ne fait qu’empirer les choses : une touche inutile pouvait toujours servir à placer les touches manquantes, comme Compose, la coupure du son (quand on reçoit un coup de fil, c’est bien plus pratique en une touche qu’en Fn + quelque chose)…

        Sinon, les dispositions (relativement) récentes pour le français comprennent d’origine l’espace insécable, voire aussi l’espace insécable fine. Avec l’Azerty OSS (« Français (variante) »), en AltGr + Espace.

        Prendre une bonne disposition : beop.free.fr

        • [^] # Re: top!

          Posté par  (site web personnel) . Évalué à 6.

          Et la mode actuelle de suppression de touches (Windows droite, Menu, Arrêt défilement…) … une touche inutile pouvait toujours servir à placer les touches manquantes, comme Compose …

          Ce journal m'a permit de m'interroger sur la touche à utiliser comme Compose. En regardant mon clavier, qui n'a ni Windows droite, ni touche menu, ni arrêt défilement (qui me servirait bien d'ailleurs), il a fallut que je me creuse la tête, ce qui fait mal. Bref avec Kde/Plasma j'ai pu facilement choisir soit AltGr+Win, soit AltGr+Ctrl gauche. C'est moche.

          En parlant de touche inutile il reste pourtant cette curieuse touche ² qui résiste. Je ne connais toujours pas son rôle et me demande bien qui peut bien faire le forcing pour qu'elle soit encore là ! Elle serait pourtant vraiment ergonomique sur un clavier AZERTY comme touche Compose.

          On peut quand même faire des trucs sympas avec cette drôle de touche : ¹²³ȩŗţşḑģḩķļçņ

          « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

          • [^] # Re: top!

            Posté par  (site web personnel) . Évalué à 4.

            Ici je n’ai eu aucun mal à trouver une bonne touche Compose, vu que sur mon clavier (QWERTY britannique) il existe très exactement une seule touche inutile : Caps Lock. Elle a aussi comme avantage d’être placée près des autres touches qu’on utilise pour les caractères "exotiques", tout ce bloc Shift, Alt, Ctrl, Super.

            • [^] # Re: top!

              Posté par  (site web personnel) . Évalué à 3.

              C'est vrai que j'ai oublié cette touche qu'on utilise qu'une fois par an ;)

              « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

          • [^] # ²

            Posté par  (site web personnel) . Évalué à 1.

            En parlant de touche inutile il reste pourtant cette curieuse touche ² qui résiste.

            Quand il n’y a pas l’option qu’on souhaiterait, il y a toujours la solution de modifier la disposition.

            Crée un fichier fr.patch avec le code ci‐dessous et applique‐le avec la commande (sous root ou avec sudo) patch -b /usr/share/X11/xkb/symbols/fr < fr.patch

            --- fr.orig 2020-06-23 00:39:38.212895439 +0200
+++ fr  2020-07-16 14:24:43.416021157 +0200
@@ -105,12 +105,12 @@
 //   © 199x-1996 René Cougnenc ✝
 //   © 1997-2002 Guylhem Aznar <clavier @ externe.net>
 //   © 2003-2006 Nicolas Mailhot <nicolas.mailhot @ laposte.net>
 //
 // ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┲━━━━━━━━━┓
-// │ ³ ¸ │ 1 ̨  │ 2 É │ 3 ˘ │ 4 — │ 5 – │ 6 ‑ │ 7 È │ 8 ™ │ 9 Ç │ 0 À │ ° ≠ │ + ± ┃ ⌫ Retour┃
-// │ ² ¹ │ & ˇ │ é ~ │ " # │ ' { │ ( [ │ - | │ è ` │ _ \ │ ç ^ │ à @ │ ) ] │ = } ┃  arrière┃
+// │ ² ¹ │ 1 ̨  │ 2 É │ 3 ˘ │ 4 — │ 5 – │ 6 ‑ │ 7 È │ 8 ™ │ 9 Ç │ 0 À │ ° ≠ │ + ± ┃ ⌫ Retour┃
+// │ ⎄ ³ │ & ˇ │ é ~ │ " # │ ' { │ ( [ │ - | │ è ` │ _ \ │ ç ^ │ à @ │ ) ] │ = } ┃  arrière┃
 // ┢━━━━━┷━┱───┴─┬───┴─┬───┴─┬───┴─┬───┴─┬───┴─┬───┴─┬───┴─┬───┴─┬───┴─┬───┴─┬───┺━┳━━━━━━━┫
 // ┃       ┃ A Æ │ Z  │ E ¢ │ R Ê │ T Þ │ Y Ÿ │ U Û │ I Î │ O Œ │ P Ô │ ¨ ˚ │ £ Ø ┃Entrée ┃
 // ┃Tab ↹  ┃ a æ │ z â │ e € │ r ê │ t þ │ y ÿ │ u û │ i î │ o œ │ p ô │ ^ ~ │ $ ø ┃   ⏎   ┃
 // ┣━━━━━━━┻┱────┴┬────┴┬────┴┬────┴┬────┴┬────┴┬────┴┬────┴┬────┴┬────┴┬────┴┬────┺┓      ┃
 // ┃        ┃ Q Ä │ S „ │ D Ë │ F ‚ │ G ¥ │ H Ð │ J Ü │ K Ï │ L Ŀ │ M Ö │ % Ù │ µ ̄  ┃      ┃
@@ -131,11 +131,11 @@
     include "keypad(oss)"

     name[Group1]="French (alt.)";

     // First row
-    key <TLDE> { [      twosuperior,    threesuperior,          onesuperior,          dead_cedilla ] }; // ² ³ ¹ ¸
+    key <TLDE> { [        Multi_key,      twosuperior,        threesuperior,           onesuperior ] }; // Compose ² ³ ¹
     key <AE01> { [        ampersand,                1,           dead_caron,           dead_ogonek ] }; // & 1 ˇ ̨
     key <AE02> { [           eacute,                2,           asciitilde,                Eacute ] }; // é 2 ~ É
     key <AE03> { [         quotedbl,                3,           numbersign,            dead_breve ] }; // " 3 # ˘
     key <AE04> { [       apostrophe,                4,            braceleft,             0x1002014 ] }; // ' 4 { — (tiret cadratin)
     key <AE05> { [        parenleft,                5,          bracketleft,             0x1002013 ] }; // ( 5 [ – (tiret demi-cadratin)

            Prendre une bonne disposition : beop.free.fr

        • [^] # Re: top!

          Posté par  . Évalué à 3.

          Ce qui est triste, c’est que les claviers PC n’aient pas la touche Compose d’origine. Et la mode actuelle de suppression de touches (Windows droite, Menu, Arrêt défilement…) ne fait qu’empirer les choses : une touche inutile pouvait toujours servir à placer les touches manquantes, comme Compose, la coupure du son (quand on reçoit un coup de fil, c’est bien plus pratique en une touche qu’en Fn + quelque chose)…

          C’est Logitech qu’il faut remercier pour cette « mode » consistant à supprimer des touches du clavier (probablement pour économiser deux centimes par clavier…). Tous ses nouveaux modèles sont sans touche « Windows droite », qui est la touche de composition par défaut sous GNU/Linux. Et le malheur, c’est l’omniprésence de cette marque dans la grande distribution et en OEM chez de grands constructeurs comme Dell.

          C’est pourtant si pratique la touche Compose pour écrire correctement des mots d’autres langues :

          • Compose, a ou n, ~ : ã ou ñ ;
          • Compose, o, / : ø ;
          • Compose, i, ' : í ;
          • Compose, s, s : ß.

          Je l’utilise aussi pour les points de suspension : Compose, ., .. Mais comme tout ceci n’est pas valable sous Windows, bah forcément c’est inutile. Comment fait-on un œ, un æ ou un É sous Windows déjà ? Sous GNU/Linux : Alt Gr + o, Alt Gr + a et enfin Verr Maj, puis é.

          Si l’on ajoute à cela l’absence totale de pilotes pour Linux pour ses divers matériels et le piètre rapport qualité/prix (à moins que vous trouviez normal qu’une souris puisse être vendue plus de cent euros), je vous invite à vous dispenser des produits de cette marque.

          • [^] # Re: top!

            Posté par  (Mastodon) . Évalué à 2.

            et enfin Verr Maj, puis é.

            Ou AltGr + Shift + é (que je trouve plus pratique puisqu'on n'active pas le VerrMaj)

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: top!

            Posté par  . Évalué à 3.

            Mais comme tout ceci n’est pas valable sous Windows

            Je viens de découvrir WinCompose (de Sam Hocevar, licence WTFPL) qui fonctionne bien pour moi après 30s de tests. Je vais pouvoir faire des É facilement !

          • [^] # Re: top!

            Posté par  . Évalué à 4.

            C’est Logitech qu’il faut remercier pour cette « mode » consistant à supprimer des touches du clavier (probablement pour économiser deux centimes par clavier…).

            Ça me paraît peu crédible. Je présume que le marché s'aligne sur les ordinateurs portables. Ils ont moins de place et s'organisent chacun à leur façon pour gagner un peu de place d'autant qu'ils ajoutent toujours la touche Fn. Ça viendrait donc plus des fabricants de PC portable qui veulent simplement gagner de la place.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: top!

        Posté par  . Évalué à 2. Dernière modification le 14 juillet 2020 à 14:45.

        merci, j'étais passé à coté !

  • # À vot' bon cœur m’sieurs dames…

    Posté par  (site web personnel) . Évalué à 3.

    Je profite de ce journal pour évoquer un rapport de bug que j'ai dernièrement ouvert et concernant le non-fonctionnement de la touche Compose dans une application, bug que le développeur de ladite application ne réussit pas à reproduire, d'où évidemment difficulté pour ce dernier de corriger ledit bug.

    De fil en aiguille, on est cependant arrivé à la conclusion qu'il y a un problème avec les dernières versions d'Electron, sur lequel s'appuie l'application en question. Du coup, j'ai essayé Chromium, sur lequel s'appuie Electron, et, effectivement, le bug survient également.

    Donc, si vous pouviez tester la touche Compose avec Chrome/Chromium et/ou avec des applications qui s'appuient sur Electron, et rapporter ici le comportement en donnant le maximum de détails sur les versions, ça aiderait le développeur en question, voire, si cela se confirme qu'il y a un bug avec Chrome/Chromium, cela permettrait d'ouvrir un rapport de bug circonstancié pour Chrome/Chromium.

    Le bug semble se produire sous Linux, mais pas sous Windows, et seulement avec des claviers non-US.

    Concrètement, chez moi, sous Kubuntu v18.0.4, avec Chromium v83.0.4103.61, Compose + o + e produit oe au lieu de œ.

    Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !

    • [^] # Re: À vot' bon cœur m’sieurs dames…

      Posté par  . Évalué à 5. Dernière modification le 15 juillet 2020 à 09:08.

      [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…).

    • [^] # Re: À vot' bon cœur m’sieurs dames…

      Posté par  . Évalué à 1.

      Alors après essai, chez moi la touche compose fonctionne sur vscode (qui est basé sur électron), sur une version chromium deggoglelisé aussi.

      Ubuntu 20.04 (wayland), clavier azerty disposition fr

      • [^] # Re: À vot' bon cœur m’sieurs dames…

        Posté par  . Évalué à 2. Dernière modification le 15 juillet 2020 à 11:38.

        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)" };
};

    • [^] # Re: À vot' bon cœur m’sieurs dames…

      Posté par  (site web personnel) . Évalué à 2.

      Pour moi, Chromium supporte manifestement les règles de composition de base, dont Compose o e → œ. Par contre, il ne supporte celles que j’ai définies dans .XCompose que si j’affecte avant la variable GTK_IM_MODULE=xim.

      Avec cette variable, sous Arch Linux (à jour) et avec Xfce comme environnement graphique, ça marche.
      Sous Xubuntu, jusqu’à la 18.04, Chromium prenait en charge les règles définies dans .XCompose, mais plus depuis qu’il a été « snappé » dans la 20.04, soit que snap ne lui permette pas d’accéder aux règles de .XCompose, soit simplement qu’il le lance sans la variable d’environnement.

      Pareil avec Visual Studio Code sous Arch Linux (je ne l’ai pas installé sous Xubuntu).

      En tout cas, pas de problème avec Compose o e.
      Peut-être ton problème est-il lié à la méthode de saisie. Tu devrais essayer d’en sélectionner une autre. Pour ma part, je n’ai pas installé ou j’ai désinstallé les méthodes de saisies « modernes » comme ibus (pour les deux systèmes), afin d’être tranquille (malgré cela, les applications GTK font de la résistance…).

      Prendre une bonne disposition : beop.free.fr

  • # Question de n00b

    Posté par  . Évalué à 2.

    Quand on en est au point de paramétrer des chemins menant vers /usr/share/X11, quel est l’avantage de la méthode « compose » par rapport à une personnalisation directe d’un fichier /usr/share/X11/xkb/symbols/FOO ?

    Par exemple:

    cat /usr/share/X11/xkb/symbols/gb
…
key <AC10>  { [
    semicolon,
    colon,
    0x100263A,
    0x100263B
    ]};

    Je n’ai pas essayé la dernière méthode, ni sur du matériel diversifié, ni dans diverses distributions, mais dans tous les cas où je l’ai appliquée, elle a bien fonctionné sans nécessiter de variables d’environnements supplémentaires ou autre désactivation de protocoles (ibus, …).

    • [^] # Re: Question de n00b

      Posté par  . Évalué à 3.

      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).

      • [^] # Re: Question de n00b

        Posté par  . Évalué à 1.

        L’avantage de ne toucher qu’un sous-répertoire de /home est indéniable.

        Quid des variables d’environnement ? Des chemins non standards1 ? Des modifications dans ibus ?

        Certes, la syntaxe des /usr/share/X11/xkb/symbols n’est pas des plus communes. Elle me semble pourtant un inconvénient mineur par rapport à désactiver ibus qui est tout de même un composant important quand on veut interagir avec différents périphériques d’E/S.

        1. « Standard » au sens large — i.e. passe-partout du moment qu’on a un X11 — pas à la façon rigoureuse du genre ISO. Par exemple, /etc/default/keyboard n’existe pas ici (Fedora 32). ↩

    • [^] # Intérêt

      Posté par  (site web personnel) . Évalué à 3.

      Quand on en est au point de paramétrer des chemins menant vers /usr/share/X11,

      Paramétrer ? Où ça ?
      J’ai juste suggéré de jeter un coup d’œil à l’existant, parce que l’existant peut déjà fournir ce qu’on cherche.
      Après, il faut bien aller le regarder là où il est…

      quel est l’avantage de la méthode « compose » par rapport à une personnalisation directe d’un fichier /usr/share/X11/xkb/symbols/FOO ?

      Ce n’est pas le même usage. On a effectivement intérêt à avoir les caractères très courants directement sur la disposition (et encore, peut-être pas tous les caractères accentués, par exemple mettre tous les caractères avec un accent circonflexe ou un tréma prendrait pas mal de place).

      Par contre, pour un caractère qu’on utilise deux ou trois fois par mois, utiliser une règle de composition a les avantages de pouvoir être mnémotechnique et de ne pas encombrer le clavier.

      Bon, et puis Compose permet de produire plus d’un caractère.
      Donc on peut l’utiliser pour produire les formules d’usage courant, aussi longues soient-elles (c’est probablement l’usage le plus courant que j’en ai). Je reproduis mon exemple :

      <Multi_key> <e> <s> : "Veuillez agréer, Madame, Monsieur, l’expression de mes sincères salutations,"

      Non seulement ça évite de passer du temps à taper des trucs sans intérêt, mais ça garantit de ne pas y faire de coquille. Bon, dans le cas de mon exemple, si tu sais à qui tu t’adresses, il faut quand même effacer la mention inutile entre « Madame » et « Monsieur » (ou ajouter d’autres règles).

      Je n’ai pas essayé la dernière méthode, ni sur du matériel diversifié, ni dans diverses distributions, mais dans tous les cas où je l’ai appliquée, elle a bien fonctionné sans nécessiter de variables d’environnements supplémentaires ou autre désactivation de protocoles (ibus, …).

      Malheureusement, il y a des développeurs qui prennent du temps pour refaire l’existant en moins bien (bon, la version Windows de Gtk peut l’expliquer, mais de là à activer et même compiler ça sous Linux…) et des distributions qui t’installent et t’activent par défaut des trucs plus gênants qu’utiles pour le français (une méthode de saisie, ça a une réelle utilité… pour le chinois).

      Prendre une bonne disposition : beop.free.fr

      • [^] # Re: Intérêt

        Posté par  . Évalué à 4.

        Paramétrer ? Où ça ?

        Tu as raison, il n’y a pas de paramétrage. Je pourrais pinailler et dire que

        cp /usr/share/X11/… ~/.XCompose

        serait de la “délocalisation” du paramétrage mais ce serait un troll déguisé …

        Quant à la génération automatique de longues incantations, c’est effectivement pratique ; je vois ça comme un moyen de généraliser :command Agréer… (vim) ou équivalent.

        Merci d’avoir clarifié tout ça.

        P.S.

        (une méthode de saisie, ça a une réelle utilité… pour le chinois).

        À l’origine, ibus n’était pas développé pour cette famille de langues. D’ailleurs, il semblerait que le mandarin et les autres variantes ne soient toujours pas proprement supportés.

        En outre, je trouve très honorable un projet qui est conçu de telle façon que les claviers soient utiles et utilisables dans une distribution, sans présumer que le public visé tapera un alphabet latin.

        • [^] # Re: Intérêt

          Posté par  (site web personnel) . Évalué à 1.

          Je pourrais pinailler et dire que

          cp /usr/share/X11/… ~/.XCompose

          serait de la “délocalisation” du paramétrage mais ce serait un troll déguisé …

          Où as‐tu vu ça ?

          Il serait contre‐productif de copier le Compose du système dans .XCompose, l’instruction include "%L" fait ce qu’il faut bien plus proprement (ça évite d’encombrer le fichier et ça prend en compte ses éventuelles mises à jour).

          Quant à la génération automatique de longues incantations, c’est effectivement pratique ; je vois ça comme un moyen de généraliser :command Agréer… (vim) ou équivalent.

          Tu peux avoir besoin d’une même formule dans un traitement de texte, dans un mail, dans un webmail (à supposer que tu utilises par exemple un client mail « lourd » pour tes messages perso et un webmail pour le boulot), dans un système de suivi de ticket… Autant utiliser un mécanisme général pour la produire.

          Qui plus est, si tu prévois des raccourcis pour ton nom, ton adresse, etc., ça peut simplifier le remplissage de formulaires en évitant le risque de coquilles qui pourraient avoir des conséquences ennuyeuses ultérieurement (bon, des fois le navigateur reconnaît l’intitulé d’un champ et propose ce que tu as mis précédemment dans un champ de même intitulé, mais ça ne fonctionne pas toujours).

          Prendre une bonne disposition : beop.free.fr

          • [^] # Re: Intérêt

            Posté par  . Évalué à 1.

            Où as‐tu vu ça ?

            Un commentaire plus haut a pointé vers cette page où on peut notamment lire :

            “To create your own set of compose keys copy the file /usr/share/X11/locale/en_US.UTF-8/Compose … to your home directory as .XCompose … and edit this file.”

            Il serait contre‐productif de copier le Compose du système …

            Oui, j’avais vu ça, c’est bien documenté dans man 5 Compose, c’est pourquoi baser un commentaire sur la page susmentionnée — ce que j’avais entrepris avant de lire Compose(5) — aurait été du pinaillage.

            Tu peux avoir besoin d’une même formule dans un traitement de texte, dans un mail, dans un webmail , dans un système de suivi de ticket …

            D’où : « je vois ça comme un moyen de généraliser … »

            • [^] # Pinailler

              Posté par  (site web personnel) . Évalué à 1. Dernière modification le 16 juillet 2020 à 15:10.

              Un commentaire plus haut a pointé vers cette page où on peut notamment lire :

              “To create your own set of compose keys copy the file /usr/share/X11/locale/en_US.UTF-8/Compose … to your home directory as .XCompose … and edit this file.”

              Je n’ai pas trouvé le dit commentaire, tu es sûr que c’était un lien direct ?

              Il serait contre‐productif de copier le Compose du système …

              Oui, j’avais vu ça, c’est bien documenté dans man 5 Compose, c’est pourquoi baser un commentaire sur la page susmentionnée — ce que j’avais entrepris avant de lire Compose(5) — aurait été du pinaillage.

              C’est peut-être sur cette page qu’il faut aller pinailler (bon, il faut d’abord se faire accepter parmi les éditeurs du wiki d’Ubuntu)…

              Prendre une bonne disposition : beop.free.fr

              • [^] # Re: Pinailler

                Posté par  . Évalué à 1.

                Je n’ai pas trouvé le dit commentaire, tu es sûr que c’était un lien direct ?

                En bout de compte, le pinaillage s’est imposé ! Le commentaire renvoie à cette page qui, dès le premier paragraphe, renvoie à l’autre page …

                Si tu contribues au wiki d’Ubuntu, peut-être que cet échange servira in fine à une modification de ce qui est apparemment une recommandation erronée.

  • # Et xev !

    Posté par  (site web personnel) . Évalué à 10.

    J'avais galéré plusieurs heures à tenter de faire marcher Compose, sans arriver à rien, et j'avais fini par jeter l'éponge. Ce journal m'a motivé à replonger dans mes soucis de Compose. En cherchant de la doc ici et là, j'ai fini par retrouver le nom d'un petit utilitaire tout bête, xev (paquet xorg-xev sur Archlinux), qui indique quelle touche envoie "quoi". Cela m'a permis de comprendre que ma touche "windows" était juste morte (ou exotique) et donc ne générais rien. Je pouvais m'acharner à l'ajouter dans les fichiers de configuration…

    Donc avant de paramétrer une touche compose : vérifier en premier lieu que cette touche génère bien un évènement dans son Linux !

    Petite astuce aussi pour ceux qui utilisent LXDE : si vous avez un gestionnaire de disposition de clavier, son paramétrage écrase les autres options et il faut donc passer par l'outil graphique pour renseigner compose:rctrl (par exemple) dans la partie "Options avancées de setxkbmap" puis cliquer sur l'icone pour sauvegarder. Ça aussi j'avais cherché un moment, ne comprenant pas pourquoi ma ligne de commande ne faisait rien…

    Maintenant je vais jouer avec .XCompose :)

    • [^] # on m'appelle?

      Posté par  . Évalué à 7.

      Quand je passerai à Wayland je changerai de pseudo pour wev.

    • [^] # Re: Et xev !

      Posté par  (Mastodon) . Évalué à 2.

      Sur mon portable, il faut que je choisisse touche windows de gauche, pour pouvoir utiliser la touche windows de droite. Comme il n´y en a pas à gauche mais juste une à droite, je suppose qu´elle retourne juste le premier code « touche windows » de la liste…

      Parfois, c´est pas très évident,mais dès qu´on a trouvé, youpalà c'est la fête, on arrête de se faire des nœuds dans le cerveau avec tout ça :)

      Et on apprends à utiliser toutes ses tentacules pour faire des compose-altGr-shift-alt-u42 ;)
      …

      Yth ^

  • # Sous Mac OS X

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 16 juillet 2020 à 22:31.

    Pour ceux que ça intéresse, on peut assez facilement simuler une touche Compose sur Mac OS X.

    Contexte : Je travaille sur un Mac au labo (on ne m’a laissé le choix qu’entre ça ou un PC sous Windows ; GNU/Linux ? pas de ça chez nous), et j’ai naturellement cherché à reproduire un environnement de travail qui me soit le plus familier possible, ce qui passe entre autres choses par la touche Compose (que j’utilise intensément sur ma machine personnelle sous GNU/Linux). Petite difficulté : je ne suis pas administrateur de la machine, donc il me fallait une solution accessible à un utilisateur non-privilégié, en particulier qui ne nécessite pas d’installer un quelconque logiciel tiers (donc, pas de Karabiner-Elements par exemple).

    Tout se passe dans un fichier ~/Library/KeyBindings/DefaultKeyBinding.dict (à créer si nécessaire). Ce fichier permet d’associer à chaque touche du clavier (ou combinaison de touches) une action arbitraire. Par exemple, ci-dessous on associe à la touche du trait d’union (aka le « tiret du 6 ») une commande insérant un tiret cadratin (c’est évidemment un exemple caricatural à ne surtout pas utiliser tel quel, sous peine de ne plus jamais pouvoir saisir un trait d‘union normal…) :

    {
    "-" = ("insertText:", "\U2014");
}

    Pour des combinaisons de touches, on procédera ainsi :

    {
    "-" = {
        "-" = ("insertText:", "\U2014");
        "." = ("insertText:", "\U2013");
    };
}

    Ici, frapper deux fois la touche du trait d’union insérera un tiret cadratin, tandis que frapper successivement le trait d’union et le point insérera un tiret demi-cadratin.

    À partir de là, on peut aisément simuler une touche Compose, il suffit de choisir la touche que l’on veut utiliser comme tel et de définir une série de combinaisons qui commencent toutes par cette touche. Dans mon cas, j’ai utilisé la touche « menu » à droite de la barre espace, qui sur ma machine a le code \U0010 (trouvé par essai et erreur, vu qu’il n’y a pas l’air d’avoir d’outil équivalent à xev sous Mac OS X — ou s’il y en a un je ne l’ai pas trouvé…). Au final ça donne le fichier suivant :

    {
    "\U0010" = { /* Compose-like key */

        "-" = {
            "m" = ("insertText:", "\U2212"); /* MINUS SIGN */
            "+" = ("insertText:", "\U2213"); /* MINUS-OR-PLUS SIGN */
            "-" = {
                "." = ("insertText:", "\U2013"); /* EN DASH */
                "-" = ("insertText:", "\U2014"); /* EM DASH */
            };
            "0" = ("insertText:", "\U2080"); /* SUBSCRIPT 0 */
            "1" = ("insertText:", "\U2081"); /* SUBSCRIPT 1 */
            "2" = ("insertText:", "\U2082"); /* SUBSCRIPT 2 */
            "3" = ("insertText:", "\U2083"); /* SUBSCRIPT 3 */
            "4" = ("insertText:", "\U2084"); /* SUBSCRIPT 4 */
            "5" = ("insertText:", "\U2085"); /* SUBSCRIPT 5 */
            "6" = ("insertText:", "\U2086"); /* SUBSCRIPT 6 */
            "7" = ("insertText:", "\U2087"); /* SUBSCRIPT 7 */
            "8" = ("insertText:", "\U2088"); /* SUBSCRIPT 8 */
            "9" = ("insertText:", "\U2089"); /* SUBSCRIPT 9 */
        };

        "_" = {
            "0" = ("insertText:", "\U2070"); /* SUPERSCRIPT 0 */
            "1" = ("insertText:", "\U2071"); /* SUPERSCRIPT 1 */
            "2" = ("insertText:", "\U00B2"); /* SUPERSCRIPT 2 */
            "3" = ("insertText:", "\U00B3"); /* SUPERSCRIPT 3 */
            "4" = ("insertText:", "\U2074"); /* SUPERSCRIPT 4 */
            "5" = ("insertText:", "\U2075"); /* SUPERSCRIPT 5 */
            "6" = ("insertText:", "\U2076"); /* SUPERSCRIPT 6 */
            "7" = ("insertText:", "\U2077"); /* SUPERSCRIPT 7 */
            "8" = ("insertText:", "\U2078"); /* SUPERSCRIPT 8 */
            "9" = ("insertText:", "\U2079"); /* SUPERSCRIPT 9 */
        };

        "g" = { /* Fly pushing stuff */
            "m" = ("insertText:", "\U2642"); /* MALE */
            "f" = ("insertText:", "\U2640"); /* FEMALE */
            "F" = ("insertText:", "\U263F"); /* VIRGIN FEMALE */
            "y" = ("insertText:", "\U21C1"); /* Y CHROMOSOME */
        };

        "G" = { /* Greek letters */
            "A" = ("insertText:", "\U0391");    /* GREEK CAPITAL LETTER ALPHA */
            "B" = ("insertText:", "\U0392");    /* GREEK CAPITAL LETTER BETA */
            "G" = ("insertText:", "\U0393");    /* GREEK CAPITAL LETTER GAMMA */
            "D" = ("insertText:", "\U0394");    /* GREEK CAPITAL LETTER DELTA */
            "E" = ("insertText:", "\U0395");    /* GREEK CAPITAL LETTER EPSILON */
            "Z" = ("insertText:", "\U0396");    /* GREEK CAPITAL LETTER ZETA */
            "Y" = ("insertText:", "\U0397");    /* GREEK CAPITAL LETTER ETA */
            "H" = ("insertText:", "\U0398");    /* GREEK CAPITAL LETTER THETA */
            "I" = ("insertText:", "\U0399");    /* GREEK CAPITAL LETTER IOTA */
            "K" = ("insertText:", "\U039A");    /* GREEK CAPITAL LETTER KAPPA */
            "L" = ("insertText:", "\U039B");    /* GREEK CAPITAL LETTER LAMBDA */
            "M" = ("insertText:", "\U039C");    /* GREEK CAPITAL LETTER MU */
            "N" = ("insertText:", "\U039D");    /* GREEK CAPITAL LETTER NU */
            "C" = ("insertText:", "\U039E");    /* GREEK CAPITAL LETTER XI */
            "O" = ("insertText:", "\U039F");    /* GREEK CAPITAL LETTER OMICRON */
            "P" = ("insertText:", "\U03A0");    /* GREEK CAPITAL LETTER PI */
            "R" = ("insertText:", "\U03A1");    /* GREEK CAPITAL LETTER RHO */
            "S" = ("insertText:", "\U03A3");    /* GREEK CAPITAL LETTER SIGMA */
            "T" = ("insertText:", "\U03A4");    /* GREEK CAPITAL LETTER TAU */
            "U" = ("insertText:", "\U03A5");    /* GREEK CAPITAL LETTER UPSILON */
            "F" = ("insertText:", "\U03A6");    /* GREEK CAPITAL LETTER PHI */
            "X" = ("insertText:", "\U03A7");    /* GREEK CAPITAL LETTER CHI */
            "Q" = ("insertText:", "\U03A8");    /* GREEK CAPITAL LETTER PSI */
            "W" = ("insertText:", "\U03A9");    /* GREEK CAPITAL LETTER OMEGA */

            "a" = ("insertText:", "\U03B1");    /* GREEK SMALL LETTER ALPHA */
            "b" = ("insertText:", "\U03B2");    /* GREEK SMALL LETTER BETA */
            "g" = ("insertText:", "\U03B3");    /* GREEK SMALL LETTER GAMMA */
            "d" = ("insertText:", "\U03B4");    /* GREEK SMALL LETTER DELTA */
            "e" = ("insertText:", "\U03B5");    /* GREEK SMALL LETTER EPSILON */
            "z" = ("insertText:", "\U03B6");    /* GREEK SMALL LETTER ZETA */
            "y" = ("insertText:", "\U03B7");    /* GREEK SMALL LETTER ETA */
            "h" = ("insertText:", "\U03B8");    /* GREEK SMALL LETTER THETA */
            "i" = ("insertText:", "\U03B9");    /* GREEK SMALL LETTER IOTA */
            "k" = ("insertText:", "\U03BA");    /* GREEK SMALL LETTER KAPPA */
            "l" = ("insertText:", "\U03BB");    /* GREEK SMALL LETTER LAMBDA */
            "m" = ("insertText:", "\U03BC");    /* GREEK SMALL LETTER MU */
            "n" = ("insertText:", "\U03BD");    /* GREEK SMALL LETTER NU */
            "c" = ("insertText:", "\U03BE");    /* GREEK SMALL LETTER XI */
            "o" = ("insertText:", "\U03BF");    /* GREEK SMALL LETTER OMICRON */
            "p" = ("insertText:", "\U03C0");    /* GREEK SMALL LETTER PI */
            "r" = ("insertText:", "\U03C1");    /* GREEK SMALL LETTER RHO */
            "v" = ("insertText:", "\U03C2");    /* GREEK SMALL LETTER FINAL SIGMA */
            "s" = ("insertText:", "\U03C3");    /* GREEK SMALL LETTER SIGMA */
            "t" = ("insertText:", "\U03C4");    /* GREEK SMALL LETTER TAU */
            "u" = ("insertText:", "\U03C5");    /* GREEK SMALL LETTER UPSILON */
            "f" = ("insertText:", "\U03C6");    /* GREEK SMALL LETTER PHI */
            "x" = ("insertText:", "\U03C7");    /* GREEK SMALL LETTER CHI */
            "q" = ("insertText:", "\U03C8");    /* GREEK SMALL LETTER PSI */
            "w" = ("insertText:", "\U03C9");    /* GREEK SMALL LETTER OMEGA */
        };

        "?" = {
            "?" = ("insertText:", "\U2E2E");    /* IRONY MARK */
            "-" = ("insertText:", "\U2243");    /* ASYMPTOTICALLY EQUAL TO */
            "=" = ("insertText:", "\U2248");    /* ALMOST EQUAL TO */
        };

        "d" = {
            "d" = ("insertText:", "\U00B0");    /* DEGREE SIGN */
            "C" = ("insertText:", "\U2103");    /* CELSIUS DEGREE */
            "F" = ("insertText:", "\U2109");    /* FARENHEIT DEGREE */
        };

        "x" = {
            "x" = ("insertText:", "\U2A09");    /* N-ARY TIMES OPERATOR */
        };

        "\U0020" = {
            "\U0020" = ("insertText:", "\U00A0");   /* NO-BREAK SPACE */
            "." = ("insertText:", "\U2008");    /* PUNCTUATION SPACE */
            "," = ("insertText:", "\U202F");    /* NARROW NO-BREAK SPACE */
            "!" = ("insertText:", "\U200B");    /* ZERO WIDTH SPACE */
        };

        "c" = {
            "o" = ("insertText:", "\U00A9"); /* COPYRIGHT SIGN */
        };
    };
}

    Voilà, si ça peut aider des Linuxiens coincés sous Mac OS X…

    La documentation d’Apple sur le sujet.

  • # XCompose : prise en charge par GTK et QT pour toutes les configurations

    Posté par  . Évalué à 1.

    Pour que .XCompose soit pris en charge, il est nécessaire de choisir la méthode de saisie XIM (ou pas de méthode de saisie) au niveau des réglages clavier de l’environnement graphique (désinstaller ibus et les méthodes de saisies est aussi une solution) et éventuellement d’insister pour certaines applications en mettant par exemple pour celles basées sur GTK dans le fichier .xprofile (ou équivalent pris en charge par l’environnement graphique) :

    GTK_IM_MODULE=xim
export GTK_IM_MODULE

    Merci @Laurent pour ce thème intéressant !

    Concernant le problème de XCompose avec GTK (et peut-être aussi avec les applications tournant avec QT), y a-t-il un moyen de le faire fonctionner pour tout environnement de bureau, pour toute distribution et pour tout gestionnaire de fenêtres ? Cela peut-il fonctionner aussi pour des utilisateurs avec des méthodes de saisie "complexes" comme par exemple le mandarin (pour ceux-ci faut-il leur recommander l'usage de fcitx avec XCompose au lieu de xim ?) ? Y a-t-il des problèmes particuliers pour les utilisateurs de GNOME ? Comment déterminer (peut-être par une ligne de commande utilisant strace et grep (?)) s'il faut ajouter export GTK_IM_MODULE=xim à ~/.xprofile, ~/profile ou ~/.bash_profile ?

    J'ai en effet défini de nombreuses combinaisons pour XCompose dont je voudrais faire bénéficier d'autres utilisateurs. Je souhaiterais aussi leur expliquer la marche à suivre pour que XCompose fonctionne sur leur machine, mais ne trouve pour le moment aucune documentation unifiée et à jour (peut-être utopique dans le monde "linuxien" ?).

    Ci-dessous un peu de documentation (souvent datée) réunie sur ce sujet :

    Dans le wiki d'Arch :

    This can be fixed by forcing GTK to use XIM by adding
    export GTK_IM_MODULE=xim and/or export XMODIFIERS="@im=none" to
    ~/.xprofile.

    En 2013 (information donc peut-être obsolète), il était question sur le wiki du site Bépo des commandes suivantes (et de ~/.bash_profile) qui pourraient également résoudre ce problème :
    sudo echo "export GTK_IM_MODULE=xim" >> /etc/profile
    echo "export GTK_IM_MODULE=xim" >> ~/.bash_profile    .

    Selon un des wikis de KDE on trouve des instructions peut-être obsolètes, à savoir la suppression de la ligne contenant run_im ibus dans .xinputrc (la ligne QT_IM_MODULE=xim y est aussi évoquée).

    En 2012, cette information a été communiquée sur ce wiki :

    To make them use your ~/.XCompose instead, add the following lines to your initialization profile (~/.bash_profile, ~/.profile,… depending on your shell and display manager):

    export GTK_IM_MODULE=xim
    export QT_IM_MODULE=xim

    D'après mon expérience, la première ligne est effectivement fonctionnelle et efficace, tandis que je ne vois pas ce qu'ajoute la seconde ligne. De plus, des logiciels comme qbittorrent ou masterpdfeditor qui tournent apparemment avec Qt, ne prennent pas en charge les combinaisons définies dans XCompose. Faut-il ajouter export QT_IM_MODULE=xim à ~/.xprofile ?

    Dans le forum d'Ubuntu, trouve le passage suivant laissant entendre que c'est le fichier ~/.profile et non pas ~/.xprofile qu'il faut modifier :

    Add the following to ~/.profile:

    export GTK_IM_MODULE="xim

    On Ubuntu 18.04 (maybe others), you may need to use the following instead:

    export GTK_IM_MODULE="gtk-im-context-simple

    Ajouter export GTK_IM_MODULE="gtk-im-context-simple dans .profile semble être la solution pour les Ubuntu à jour à en croire cette réponse sur leur forum, même si cette réserve peut être apportée :

    So the gtk-im-context-simple method has a built-in table and it loads compose sequences from several additional locations. That means it could possible load shorter sequences that you don't expect. The name "simple" is a bit misleading here really. It would be nice if there was a tool that looks for sequence collissions based on the same algorithm that gtk-im-context-simple uses to load it's tables.

    Le wiki d'Ubuntu sur ce point paraît dater, pour sa dernière modification de 2008. Invraisemblable que les informations soient toujours valides, n'est-ce pas ? C'est ce que je crois de plus avoir lu dans un des commentaires de ce journal.

    Merci encore pour avoir abordé cette thématique et merci par avance pour votre réponse (en espérant ne pas vous avoir assommé par la longueur de ce message !)

    • [^] # Re: XCompose : prise en charge par GTK et QT pour toutes les configurations

      Posté par  . Évalué à 3.

      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.

      • [^] # Re: XCompose : prise en charge par GTK et QT pour toutes les configurations

        Posté par  . Évalué à 1.

        Merci @jyves pour votre réponse.
        Pour l'instant, la meilleure configuration que j'ai trouvée, fonctionne avec XIM et export GTK_IM_MODULE='xim' configuré dans ~/.xprofile. Mon problème est que les logiciels tournant avec QT ne prennent pas mes configuration de XCompose en considération alors que cela fonctionne bien avec ceux fonctionnant avec GTK, comme LibreOffice.
        M'indiquez-vous FCITX pour le mandarin ou même pour des écritures alphabétiques moins complexes ?
        Merci encore !

        • [^] # Re: XCompose : prise en charge par GTK et QT pour toutes les configurations

          Posté par  . Évalué à 3. Dernière modification le 24 juillet 2020 à 10:46.

          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.

          • [^] # KDE ?

            Posté par  (site web personnel) . Évalué à 2.

            Si tu utilises fcitx, peut‐être es‐tu sous KDE. Si c’est le cas, est‐ce que les raccourcis définis dans .XCompose et produisant une chaîne de plus d’un caractère fonctionnent pour toi ?

            Prendre une bonne disposition : beop.free.fr

            • [^] # Re: KDE ?

              Posté par  . Évalué à 1.

              Si tu utilises fcitx, peut‐être es‐tu sous KDE. Si c’est le cas, est‐ce que les raccourcis définis dans .XCompose et produisant une chaîne de plus d’un caractère fonctionnent pour toi ?

              Bonne question ! En effet, mes combinaisons définies dans .XCompose sont très majoritairement composées de chaînes de plus d'un caractère, comme un diacritique et une voyelle par exemple. Je suis curieux de savoir si c'est le cas pour vous @jyves.

              Un grand merci pour vos retours @jyves et Laurent !

            • [^] # Re: KDE ?

              Posté par  . Évalué à 4.

              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.

    • [^] # Gnome et KDE

      Posté par  (site web personnel) . Évalué à 2.

      Il m’a fallu un peu de temps pour tester (je ne trouvais plus de clé USB disponible et avec une machine qui n’est pas un foudre de guerre, faire tourner une machine virtuelle avec KDE ou pire Gnome, c’est à mourir de vieillesse…).

      Y a-t-il des problèmes particuliers pour les utilisateurs de GNOME ? Comment déterminer (peut-être par une ligne de commande utilisant strace et grep (?)) s'il faut ajouter export GTK_IM_MODULE=xim à ~/.xprofile, ~/profile ou ~/.bash_profile ?

      Ça a beaucoup fluctué (comme beaucoup de choses sur Gnome…). À une époque, il fallait utiliser .gnomerc, puis il fallait spécifier un fichier à lancer au démarrage dans les paramètres, puis il n’était plus possible de définir aucune variable au démarrage de Gnome/Wayland, même pas le PATH (!), celui-ci se lançant directement sans lancer de shell.

      Apparemment maintenant, gnome-session lance à nouveau un login shell avant de démarrer Gnome (pas clair de savoir quel est le patch finalement retenu, donc si c’est le shell configuré pour l’utilisateur ou systématiquement bash).
      Il faut donc définir la variable dans le fichier exécuté par le shell quand il est lancé avec l’option -l. Pour bash, c’est .bash_profile.

      Pour les applications Qt, ça a fluctué aussi. À un moment, il fallait définir QT_IM_MODULE.
      À l’essai, ça ne semble plus avoir d’influence maintenant.

      Avec l’éditeur Tea, le logiciel basé sur Qt que j’utilise pour tester, tout fonctionne pour moi directement sans problème… sous Xfce !

      Sous KDE, c’est plus mitigé. fcitx a pris la place des autres méthodes d’entrées en permettant de mixer leurs possibilités et il semble aussi supporter directement .XCompose… sauf la possibilité de produire plus d’un caractère.
      Adieu les raccourcis si pratiques (avec mon raccourci pour la formule de politesse, je n’obtiens que la lettre V) !
      J’ai essayé avec deux distributions différentes, openSUSE et Kubuntu, même problème.

      Définir "export GTK_IM_MODULE=xim" sauve la mise pour les logiciels GTK (même sous KDE).

      Mais pour les logiciels KDE sous KDE, je n’ai trouvé aucune issue. Ni sélectionner la bonne vieille méthode d’entrée de X11 (xim) avec im-config, ni désinstaller fcitx n’ont résolu le problème à l’essai (j’ai bien fermé et rouvert la session pour que ce soit pris en compte, au cas où quelqu’un se poserait la question).

      J’ai l’impression que les développeurs actuels les plus prolifiques sous Linux n’apprécient pas ou même ne connaissent pas les petits plus historiques apparus dans le monde Unix ou X11 et qui l’ont rendu bien agréable à utiliser (la touche Compose, l’affichage distant, la sélection automatique de la fenêtre sous le pointeur souris…).

      Du coup, quand ils refont quelque chose (ce qui arrive souvent avec Gnome et KDE, moins avec les environnements graphiques qui ont moins de développeurs), on perd éventuellement ces petits plus (ou carrément la possibilité de définir le PATH !), au moins jusqu’à ce qu’il y ait assez de gens qui s’en plaignent (je ne sais pas où en est la possibilité d’affichage distant sous Wayland)…

      Prendre une bonne disposition : beop.free.fr

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.