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 Bruce Le Nain (site web personnel) . Évalué à 2.
L'apostrophe de ton titre est faite avec compose?
[^] # Disposition
Posté par _Laurent_ (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 Bruce Le Nain (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 _Laurent_ (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…).
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 Anonyme . Évalué à 3.
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 _Laurent_ (site web personnel) . Évalué à 2.
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 Anonyme . Évalué à 2.
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 _Laurent_ (site web personnel) . Évalué à 1. Dernière modification le 16 juillet 2020 à 12:20.
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 Anonyme . Évalué à 2.
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
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.
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)
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 Anonyme . Évalué à 1.
Alt-gr + Shift + G sur fr-oss.
[^] # Re: Apostrophe
Posté par _Laurent_ (site web personnel) . Évalué à 2.
Non, pas Shift, juste AltGr. Extrait de
/usr/share/X11/xkb/symbols/fr
:Prendre une bonne disposition : beop.free.fr
[^] # Re: Apostrophe
Posté par Anonyme . Évalué à 2.
Ouais, je me suis rendu compte de mon erreur trop tard pour corriger. Vous pouvez moinsser.
[^] # Re: Apostrophe
Posté par sebas . É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 Anonyme . Évalué à 3.
Je viens de rajouter un non-breaking space dans mon .Xcompose:
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 _Laurent_ (site web personnel) . Évalué à 1.
Deux pistes :
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 _Laurent_ (site web personnel) . Évalué à 3. Dernière modification le 14 juillet 2020 à 14:17.
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 sebas . Évalué à 4.
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 _Laurent_ (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 deuzene (site web personnel) . Évalué à 6.
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 vv222 . É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 blocShift
,Alt
,Ctrl
,Super
.[^] # Re: top!
Posté par deuzene (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 _Laurent_ (site web personnel) . Évalué à 1.
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
Prendre une bonne disposition : beop.free.fr
[^] # Re: top!
Posté par Davy Defaud . Évalué à 3.
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
oun
,~
: ã 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 enfinVerr 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 gUI (Mastodon) . Évalué à 2.
Ou
AltGr
+Shift
+é
(que je trouve plus pratique puisqu'on n'active pas leVerrMaj
)En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: top!
Posté par Olivier Abad . Évalué à 3.
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 barmic 🦦 . Évalué à 4.
Ç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 Anonyme . É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 Claude SIMON (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
produitoe
au lieu deœ
.Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: À vot' bon cœur m’sieurs dames…
Posté par jyes . É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 »]
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 matteli . É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 jyes . É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 :
[^] # Re: À vot' bon cœur m’sieurs dames…
Posté par _Laurent_ (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
[^] # Re: À vot' bon cœur m’sieurs dames…
Posté par jyes . Évalué à 4.
Ç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.
# Question de n00b
Posté par gipoisson . É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:
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 jyes . É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 gipoisson . É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ésactiveribus
qui est tout de même un composant important quand on veut interagir avec différents périphériques d’E/S.« 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 _Laurent_ (site web personnel) . Évalué à 3.
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…
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 :
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).
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 gipoisson . Évalué à 4.
Tu as raison, il n’y a pas de paramétrage. Je pourrais pinailler et dire que
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.
À 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 _Laurent_ (site web personnel) . Évalué à 1.
Où as‐tu vu ça ?
Il serait contre‐productif de copier le
Compose
du système dans.XCompose
, l’instructioninclude "%L"
fait ce qu’il faut bien plus proprement (ça évite d’encombrer le fichier et ça prend en compte ses éventuelles mises à jour).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 gipoisson . Évalué à 1.
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.”
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 lireCompose(5)
— aurait été du pinaillage.D’où : « je vois ça comme un moyen de généraliser … »
[^] # Pinailler
Posté par _Laurent_ (site web personnel) . Évalué à 1. Dernière modification le 16 juillet 2020 à 15:10.
Je n’ai pas trouvé le dit commentaire, tu es sûr que c’était un lien direct ?
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 gipoisson . Évalué à 1.
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 Zatalyz (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 Anonyme . Évalué à 7.
Quand je passerai à Wayland je changerai de pseudo pour wev.
[^] # Re: Et xev !
Posté par Yth (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 gouttegd . É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…) :Pour des combinaisons de touches, on procédera ainsi :
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 :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 Nuxli . Évalué à 1.
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 :
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 ligneQT_IM_MODULE=xim
y est aussi évoquée).En 2012, cette information a été communiquée sur ce wiki :
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 :
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 :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 jyes . É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 Nuxli . É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 jyes . É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 _Laurent_ (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 Nuxli . Évalué à 1.
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 jyes . É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 _Laurent_ (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…).
Ç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.