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)...
[^] # Gnome et KDE
Posté par _Laurent_ (site web personnel) . En réponse au journal Qu’on pose. É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