[Slim] clavier / caractères accentués (résolu)

[Silejonu]

Si ça peut aidé, j'avais remarqué le même problème. J'en avais conclu qu'on ne pouvait de toute façon pas utiliser de caractères accentués dans un nom d'utilisateur, et j'avais pas cherché plus loin. Visiblement, je me trompe.

[benjarobin]

Je travail actuellement au port de slim pour le support de l'unicode. Ce n'est pas une tache très facile, car c'est assez bas niveau (Récupération des événements des touches du clavier)

[FoolEcho]

[Silejonu]

Et bien merci et bon courage.

[kamui57]

Je travail actuellement au port de slim pour le support de l'unicode. Ce n'est pas une tache très facile, car c'est assez bas niveau (Récupération des événements des touches du clavier)

chapeau

[benjarobin]

Voila le travail : http://benjarobin.fr/Program/ArchLinux/ ... ode.tar.gz
Ce qui est intéressant dans l'archive c'est unicode.patch, tout le reste est inchangé.
Attention comme même, c'est peu voir pas testé... Désolé mais si je trouve 5 min je test Mais je compte sur vous pour refaire remonter les bug introduit

[FoolEcho]

Je teste ça dans la journée, merci !



Je n'ai testé qu'avec ma disposition de clavier habituel (fr/latin9) et locale en fr_FR.utf-8, mais ça paraît fonctionner au poil !
Les caractères non ascii sont saisis et apparaissent normalement cette fois.

Par contre, deux bugs (peut-être liés):
-l'affichage des messages s'il contiennent des caractères non ascii a disparu (par exemple, dans le slim.conf en modifiant "The system is halting..." par "Arrêt du système" ou tout autre message incluant des caractères non ascii, comme username/password si on touche au thème)
-un mot de passe avec caractères non ascii ne passe pas (bien que la saisie paraisse correcte au nombre de caractères masqués, ce qui n'était pas le cas avant).

[benjarobin]

Oula, j'avais comme même un minimum testé mais là j'ai l'impression de n'avoir pas testé les fonction de base... Je suis désolé, je vais revoir ma copie... En plus tu es dans une configuration "Simple" (En utf-8), normalement avec une locale latin-9 (fr_FR@euro) tu devrai pouvoir utiliser le signe €. Bref je vais voir tout ceci en détail ce soir

[FoolEcho]

Je n'ai pas vérifié pour d'autres locales, je n'ai lâchement testé que le fr_FR.UTF-8 que j'utilise.

Y a déjà du mieux, vu qu'on ne pouvait même pas saisir les caractères non ascii au clavier avant (donc connexion également impossible avant).
Prends ton temps.

[benjarobin]

Mise à jour faite, "Quelques" bugs ont été corrigés , même lien

[FoolEcho]

Ça ne change rien... (toujours clavier fr/latin9 et locale fr_FR.UTF-8)
J'ai testé la francisation des messages, dans le slim.conf et dans un thème, toujours pareil, rien ne s'affiche (bon, en fait, je ne sais pas si tu corriges ça aussi).
Connexion avec un mot de passe "éééé", échec aussi. Le log de slim indique:

Code : Tout sélectionner

slim: pam_authentication(): Authentication failure

Tu es sûr d'avoir mis le bon tar en ligne (je n'ai pas comparé avec l'ancien) ? ... mais ça vient peut-être de moi (je me suis déjà gourré en récupérant ton archive et je n'ai clairement plus les yeux en face des trous ce soir, je verrai demain).

[benjarobin]

Le problème n'est pas dans slim, mais dans /etc/rc.d/functions qui définit LANG=C
Je cherche à comprendre, je te tient au courant
Si tu veux tester slim, lance en root :

Code : Tout sélectionner

LC_ALL=fr_FR.UTF-8 slim

Edit: J'ai compris, rajoute dans /etc/rc.d/slim juste après

Code : Tout sélectionner

. /etc/rc.conf

Code : Tout sélectionner

export DAEMON_LOCALE=yes

Edit2: J'ai mit à jour l'archive pour tenir compte de ce changement. Je comprend mieux pourquoi cela ne fonctionnait pas

Edit3: Par contre je ne comprend pas comment KDM fait pour connaître la locale courante, si quelqu'un à une idée ? Car la saisie d'un mot de passe est locale dépendant: le mot de passe n'est pas analysé en fonction de la locale courante (Saisir le mot de passe "bén" en Latin9 fait 3 octets, tandis qu'en UTF-8, 4 octets...). Par contre la lecture des touches du clavier est locale indépendant et dépend de la disposition du clavier...

[FoolEcho]

Bonne nouvelle, tout marche au poil (affichage des messages / saisie de mots de passe avec caractères non ascii) si je démarre slim manuellement:

Si tu veux tester slim, lance en root :

Code : Tout sélectionner

LC_ALL=fr_FR.UTF-8 slim

(c'était peut-être le cas dès hier, mais je n'avais pas cherché à le lancer comme ça )

Fonctionne aussi en lançant slim en tant que service dans le rc.conf.

Par contre, «forcément», je retombe sur le comportement déficient en passant par inittab.

Sinon, j'ai fait l'essai: tu n'as pas besoin de rajouter l'export DAEMON_LOCALE dans le /etc/rc.d/slim (chez moi il est bien à yes dans le rc.conf... et vu que ce dernier est inclu).

Ça avance, ça avance. Excellent boulot, déjà.



EDIT: Pour Kdm, je serai bien incapable de te le dire, par contre il y a pléthore de scripts auquel il se refère, cf. kdmrc ( tous dans /usr/share/config/kdm/ ... bon après, c'est peut-être/probablement codé en dehors de ça, ça pourrait valoir le coup de voir comment est fait l'exécutable kdm -- ou voir du côté de lxdm qui se débrouille bien aussi , je ne sais pas...).

EDIT: pour lxdm c'est un script bash dans /usr/sbin/lxdm (c'est lui qu'on lance par l'inittab), qui se contente d'inclure la locale du système (LANG) avant de lancer le binaire /usr/sbin/lxdm-binary ... ... suivez mon regard...

EDIT: à priori, kdm analyse par ses propres moyens (directement un binaire).

EDIT: Je viens de tester vite fait, sur le modèle de lxdm et la solution manuelle, on peut rajouter un script simple et l'appeler dans l'inittab, tout paraît fonctionner.
Par exemple, /usr/bin/slim.sh (le nom et l'emplacement sont pourris):

Code : Tout sélectionner

#!/bin/sh

if [ -r /etc/profile.d/locale.sh ]; then
        . /etc/profile.d/locale.sh
fi

if [ -n "$LANG" ];then
        export LANG
fi

exec /usr/bin/slim

(LANG est suffisant)
Et modifier l'inittab en conséquence:

Code : Tout sélectionner

x:5:respawn:/usr/bin/slim.sh >& /dev/null

(@benjarobin: ridicule contribution de ma part, s'il en est... pour le cas où tu l'adoptes, si tu n'as pas une meilleure solution, prière de trouver un nom de fichier moins pourri )

[benjarobin]

Cette solution je l'avais Mais il était tard... De plus j'aimerais comprendre comment fait KDM...
Pour l'instant je vais inclure un mixte de ta solution et de la mienne

Edit: Voila mis à jour
Je ne sais pas vraiment comment faire pour "officialiser" ceci... AUR ?

[HacKurx]

Pourquoi pas avec un mail à iwamatsu(at)debian(dot)org

[FoolEcho]

Tu parles du mainteneur de slim pour Debian ? (en admettant qu'il s'en occupe toujours)

Possible... mais pour moi, il faudrait mieux directement proposer le patch sur le bugtracker de slim, c'est quand même une fonctionnalité supplémentaire (cf. liens précédents sur les rapports de bug que j'ai pondu -- j'en avais fait deux car je n'étais pas sûr que les deux problèmes puissent se résoudre d'un coup, ni même qu'ils étaient liés): même si ça à l'air en stand-by, il y a encore quelques patchs qui se sont trouvés intégrés depuis un an. J'allais d'ailleurs te demander si tu allais proposer ton patch là-bas.

Et en attendant, vu que l'ensemble a l'air de fonctionner correctement selon les cas d'usage (manuel/rc.conf/inittab - mots de passe avec caractères non-ascii et au moins clavier fr), Aur est probablement une bonne solution: ça donnera plus de poids à une éventuelle intégration/reprise du projet... et remontée de bugs qu'on aurait loupé.

Du coup, probablement renommer le paquet en slim-unicode ? (fournissant slim / conflit slim)

@benjarobin: par contre, dans le fichier install, précise la prise en compte du script pour inittab: x:5:respawn:/usr/bin/[b]slim.sh[/b] >& /dev/null.

[benjarobin]

Je te conseil de télécharger à nouveau l'archive contenant le patch. Normalement c'est 100% transparent pour l'utilisateur, rien à renommer.
Le fichier binaire est dans /usr/share/gtkterm tandis que le lancer est dans /usr/bin
Mais cela me fait penser que je dois changer le lanceur, en effet si LANG est déjà définie je dois en tenir compte et non l'écraser. Quelque chose comme :

Code : Tout sélectionner

#!/bin/bash

if [ -z "$LANG" ]; then
	if [ -r /etc/profile.d/locale.sh ]; then
		. /etc/profile.d/locale.sh
	fi
	
	if [ -n "$LANG" ];then
		export LANG
	fi
fi
exec /usr/share/slim/slim "$@"

[FoolEcho]

Habile et propre. Autant pour moi, je n'avais que parcouru l'archive cette fois.
Pour pinailler quand même, tu pourrais éventuellement mettre le binaire de slim non pas dans /usr/share/slim/, mais dans /usr/share/slim/bin/ (rien d'obligatoire cependant).

en effet si LANG est déjà définie je dois en tenir compte et non l'écraser

C'est tangent... J'aurais tendance à te dire que vu qu'on a le binaire qu'on peut toujours lancer pour le changement de locale, ça ne valait pas le coup d'ajouter un test... ... ... mais si tu privilègies l'usage du script et compte tenu que le binaire lui n'est pas dans le PATH, ça peut valoir le coup... Oui, dans le fond, c'est pas idiot en fait.

[HacKurx]

Tu parles du mainteneur de slim pour Debian ? (en admettant qu'il s'en occupe toujours)

Sur le site c'est écrit "The current SLiM maintainer is Nobuhiro Iwamatsu" c'est donc une de ses adresses mail.

[FoolEcho]

Je n'avais pas vérifié, j'avais seulement en mémoire que ce bug a été rapporté en 2009, donc bon, il peut s'en passer depuis.

Il n'empêche, la fonctionnalité apportée par benjarobin est plus du ressort des (futurs ?) développeurs de slim. De notre côté, on s'en fiche pas mal que Debian intègre ou non ce patch (même si je suppose qu'on a en récupéré certains)... Bon, après, rien n'empêche de signaler chez Debian qu'il existe maintenant une solution (pour une fois que c'est du côté d'Arch qu'un patch est proposé ).