This is the old SliTaz forum - Please use the main forum.slitaz.org

CR sur Slitaz-xorg et l'unicode
  • LuXLuX January 2010
    Bonjour,

    voici donc mes premières remarques après installation de la saveur slitaz-xorg. J'ai téléchargé l'iso que j'ai décompressée et installée sur une partition de mon disque dur, comme d'habitude. Tout d'abord une bonne nouvelle : avec les options "vga=792 lang=fr_FR.UTF-8 kmap=fr-latin1" passées à Grub, Slitaz boot sur mon portable en mode graphique du premier coup. Quel changement !
    :-))

    Mon clavier azerty et ma souris filaire sont reconnues. Voici maintenant la liste des problèmes que j'ai relevés (après avoir tazpékagé un recharge/upgrade, of course !).

    I. Les trucs généraux

    • * La taille de l'écran parait surévaluée en mode X (il affiche une image plus grande que l'écran) même si je passe à Grub l'option screen=ma_résolution. Ça vient de xorg, qui utilise le driver "vesa" au lieu du driver "trident" adapté à ma carte graphique. Une fois installé xorg-xf86-video-trident et modifié une ligne dans le fichier xorg.conf (dans la section "Device", remplacer 'Driver "vesa"' par 'Driver "trident"') le problème est réglé.
    • * Pas de lxpanel, comme je le rapportais déjà pour la Cooking. Du coup pas de menu d'applications façon Gnome, et toute fenêtre iconifiée disparaît définitivement. C'est génant !
    • * Le menu d'openbox, celui qu'on obtient en cliquant droit sur le fond de l'écran, est en anglais. De plus "Favorite applications -> Web Browser" lance firefox... qui n'est pas installé, donc ne produit rien. Cette entrée devrait plutôt pointer sur netsurf, dans cette saveur.
    • * Dans netsurf, justement, les menus sont en anglais et la sélection à la souris d'une portion de page ne permet pas d'en copier le texte. On ne peut pas non plus sélectionner tout ou partie du contenu de la barre d'adresse. Est-ce un problème de netsurf lui-même ou juste une option de compilation oubliée ? En tout cas ça rend ce navigateur peu pratique, alors que par ailleurs il n'est pas si mauvais.
    • * Le démarrage de udhcpc marche moins bien pour moi qu'avec Slitaz 2.0. Lors du boot j'ai la plupart du temps la série de messages suivants (quelque fois la connection se fait avant la troisième tentative, mais rarement) :
      udhcpc (v1.12.0) started
      Sending discover...
      Sending discover...
      Sending discover...
      No lease, forking to background

      Une fois passé le boot, la connection marche effectivement, mais la commande rdate que je dois lancer à la fin du boot (je l'ai mise dans /etc/init.d/local.sh) pour avoir une heure correcte ne passe pas. Comme aucun réglage de /etc/TZ ne m'a jamais permis d'avoir l'heure correcte en toutes saisons dans Slitaz, je me retrouve sans remède contre ce problème. Avec 2.0 l'intervalle entre chaque tentative "Sending discover..." était un poil plus long, me semble-t-il, mais il aboutissait la plupart du temps avant la troisième. Y a-t-il un moyen de ralentir un chouïa cette étape ?


    II. Les (émulateurs de) terminaux et l'unicode

    Pour avoir l'encodage UTF-8 j'ai passé à Grub l'option lang=fr_FR.UTF-8 et ça a marché... à moitié seulement. Les variables $LC_ALL et $LANG ont la valeur attendue. Quand j'ouvre dans une application graphique (leafpad, geany) un fichier de texte en UTF-8 il l'affiche convenablement malgré un message d'erreur pour leafpad (curieusement pas pour geany) :

    $ leafpad u8.txt  

    (process:1553): Gtk-WARNING **: Locale not supported by C library.
            Using the fallback 'C' locale.


    On a des messages du même genre dés qu'on lance un terminal ou un shell (commande 'bash'), entre autres.

    Il y a apparemment quatre émulateurs de terminaux installés par défaut : 
    $ ls /usr/bin/*term*
    /usr/bin/koi8rxterm  /usr/bin/uxterm
    /usr/bin/terminal    /usr/bin/xterm


    En fait le premier ne marche pas :
    $ koi8rxterm  
    koi8rxterm tried to use locale ru_RU.KOI8-R by setting $LC_ALL
    /usr/bin/koi8rxterm: line 1: xmessage: not found


    Quant à terminal ce n'est pour l'instant (voir plus loin) qu'un script de quelques lignes qui appelle "xterm". Inutile d'essayer de leur parler UTF-8 : ils ne savent pas. On peut quand même saisir un "é" dans la ligne de commande, ce qui permet de vérifier qu'il est alors en Latin1 :
    $ echo -n é | wc -c
    1


    uxterm semble donc le seul terminal disponible par défaut dans slitaz-xorg qui supporte (plus ou moins) l'unicode. Ce serait donc mieux si on avait "$TERM=uxterm" au lieu de "$TERM=xterm". De même l'entrée "Applications -> Terminal" du menu d'Openbox devrait lancer uxterm plutôt que xterm.

    Dans uxterm, l'affichage d'un texte ou d'une chaine en UTF-8 avec echo, cat, less ou nano (EDIT1: Ben non, pas nano en fait, je me suis trompé. EDIT2: En fait si, c'est seulement après l'appel à localedef --plus loin-- que nano n'affiche plus correctement l'unicode) est nickel. Pas avec vi, mais il suffit de le remplacer par vim-tiny, qui supporte l'unicode. En passant on vérifie qu'on est vraiment en UTF-8 dans uxterm :
    $ echo -n é | wc -c
    2


    Là ou ça se gâte c'est pour la saisie et surtout l'effacement. Je saisis (du moins j'essaye) 6 "é" dans la ligne de commande et j'efface ensuite tout ce que je peux.
    - Dans xterm : pas de problème (normal, on est en Latin1).
    - Dans uxterm : saisie correcte, mais ce sont ensuite 12 caractères qui sont effacés, ne laissant qu'un prompt tronqué : "tux@slit" au lieu de "tux@slitaz:~$ " !! Ce bug est connu, voir plus loin.
    - Dans Terminal (que j'ai installé entre deux) : saisie incorrecte, les "é" (et autres caractères accentués) sont remplacés par des "?". En revanche on n'efface bien "que" 6 caractères.
    - Dans urxvt : toute petite fenêtre, et ce terminal soi-disant unicode se comporte en fait exactement comme xterm.

    Je note en passant qu'une fois installé "Terminal", dont le paquet s'appelle maintenant "terminal", le script /usr/bin/terminal" est remplacé par un lien vers "Terminal", ce qui est une bonne idée.

    J'ai aussi installé le paquet urxvt-full, pour voir si ça améliorait ules choses pour rxvt. Pas un franc succès :
    $ urxvt
    urxvt: default locale unavailable, check LC_* and LANG variables. Continuing.
    perl: warning: Setting locale failed.
    perl: warning: Please check that your locale settings:
            LANGUAGE = (unset),
            LC_ALL = "fr_FR.UTF-8",
            LANG = "fr_FR.UTF-8"
        are supported and installed on your system.
    perl: warning: Falling back to the standard locale ("C").
    Can't locate utf8.pm in @INC (@INC contains: /usr/lib/urxvt /usr/lib/perl5/5.10
    .0/i686-linux /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.10.0/i686-linux 
    /usr/lib/perl5/site_perl/5.10.0 .) at /usr/lib/urxvt/urxvt.pm line 706.
    BEGIN failed--compilation aborted at /usr/lib/urxvt/urxvt.pm line 706.
    Compilation failed in require at -e line 1.
    BEGIN failed--compilation aborted at -e line 1.
    urxvt: unable to initialize perl-interpreter, continuing without.

    Ce qui produit la même petite fenêtre de terminal que précédemment, sans support de l'unicode.

    III. Installer la locale... et bash

    Le bug dans uxterm est connu. D'après ce que j'avais compris l'an dernier sur le forum et le wiki de Slitaz, il est dû au fait que le shell ash fourni par busybox utilise sa propre librairie Readline, qui n'est pas adaptée à l'unicode. La solution que j'ai trouvée l'an dernier consistait à installer bash, qui utilise apparemment la vraie Readline, et à en faire le shell par défaut.

    J'ai donc essayé ça, et eu la surprise de voir que ça ne fonctionnait pas. Non seulement ça ne changeait rien dans "Terminal", mais dans "xterm" et "uxterm" il n'était même plus posible de saisir des caractères accentués.

    En fait pour que ça fonctionne il faut commencer par définir la bonne locale. En effet, même si le système positionne au départ les variables comme il faut et fournit les fontes ad hoc, curieusement il oublie d'installer la locale. La preuve :
    tux@slitaz:~$ locale -a       
    locale: Cannot set LC_CTYPE to default locale: No such file or directory
    locale: Cannot set LC_MESSAGES to default locale: No such file or directory
    locale: Cannot set LC_COLLATE to default locale: No such file or directory
    C
    POSIX
    de_DE
    es_ES
    fr_FR
    pt_BR


    J'ai donc suivi le wiki :
    $ tazpkg get-install glibc-locale
    $ localedef -i fr_FR -c -f UTF-8 /usr/lib/locale/fr_FR.UTF-8


    Après cela les messages d'avertissement comme quoi la locale n'est pas supportée deviennent un peu moins fréquent (on n'en a plus quand on lance leafpad ou bash, par exemple, ou après "locale -a", mais on en a encore quand on lance un terminal (xterm ou uxterm) : 
    $ xterm
    Warning: locale not supported by Xlib, locale set to C


    Cependant on n'a pas de message comme cela quand on lance "Terminal". Et surtout dans chacun de ces trois terminaux la saisie et l'effacement de caractères accentués dans la ligne de commande fonctionnent désormais correctement, uniquement en bash bien sûr, pas en sh.

    Pour urxvt c'est plus mitigé : l'affichage avec echo, cat ou less est correct. Le lancement de nano produit une erreur : 
    tux@slitaz:~$ nano u8.txt 
    Error opening terminal: rxvt-unicode.

    Et aucun moyen de saisir des caractères accentués au clavier.

    Tiens, ça faisait longtemps que Vanilla ne m'avait pas reproché la longueur de mes messages ! Je conclus donc dans le suivant.
  • LuXLuX January 2010
    IV. Conclusion

    Le labs annonce fièrement que Slitaz 3.0 offrira un support complet de l'unicode. Je crois que ce n'est pas encore tout-à-fait le cas. Au minimum il faudrait, quand l'option "lang=***.UTF-8" est passée au démarrage :
    - que la locale correspondante soit effectivement créée par localedef ;
    - que $TERM pointe vers uxterm ;
    ---EDIT (02/02/10) : ou mieux encore, vers vte-terminal s'il est présent par défaut (voir suite de la discussion)---
    - que le bug de la readline de busybox soit fixé d'une manière ou d'une autre, et pour ma part je ne connais pas d'autre alternative que de remplacer le sh de busybox par un vrai bash qui soit le shell par défaut pour tous les utilisateurs ;
    - faire en sorte que ces messages bizarres sur la locale non supportée disparaissent (mais je me doute que que vous avez déjà dû tout essayer !).

    Il y a aussi quelques bugs dans les paquets : toujours pas mal d'icônes absentes de "Terminal", et "urxvt" qui n'offre qu'un support partiel de l'unicode (problème de saisie même après intallation de la locale).

    J'espère que ce long rapport aidera à améliorer la prochaine version. Cordialement,

    LuX.
  • GokhlayehGokhlayeh January 2010
    Bonjour LuX,

    Merci pour ces informations, je voudrais utiliser UTF-8 mais pour le moment cela à l'air plutôt compliqué, et je suis déjà occupé par 2/3 autres trucs...

    Je voulais te signaler l'existence du terminal vte :
    tazpkg get-install vte-terminal
    vte


    J'ai aussi une recette pour compiler lxterminal avec tazwok :
    # SliTaz package receipt.

    PACKAGE="lxterminal"
    VERSION="0.1.6"
    CATEGORY="utilities"
    SHORT_DESC="LXDE X Terminal emulator."
    MAINTAINER=""
    DEPENDS="vte gtk+"
    BUILD_DEPENDS="intltool vte-dev vte-terminal pkg-config autoconf automake"
    TARBALL="$PACKAGE-$VERSION.tar.gz"
    WEB_SITE="http://lxde.org"
    WGET_URL="http://downloads.sourceforge.net/project/lxde/LXTerminal%20%28terminal%20emulator%29/LXTerminal%200.1.6/$TARBALL"

    # Rules to configure and make the package.
    compile_rules()
    {
    	cd $src
    	./configure \
    		--prefix=/usr \
    		--infodir=/usr/share/info \
    		--mandir=/usr/share/man \
    		$CONFIGURE_ARGS &&
    	make && make DESTDIR=$PWD/_pkg install
    }

    # Rules to gen a SliTaz package suitable for Tazpkg.
    genpkg_rules()
    {
    	mkdir -p $fs/usr
    	cp -a $_pkg/usr/bin $fs/usr
    	cp -a $_pkg/usr/share $fs/usr
    	# Remove man
    	rm -rf $fs/usr/share/man
    }


    (il manque peut être des paquets dans depends ou builds_depends, je suis intéressé par tout rapport d'erreur ; il manque aussi une dépendance à intltool : gettext)

    Je n'ai aucune idée de la qualité du support de l'UTF-8 par ces terminaux et cela m'interesse, donc si tu as envie de tester n'hésite pas à poster tes résultats ;)

    Je voudrais aussi que tu répondes à ces questions :
    Qu'implique d'intégrer bash comme shell par défaut en terme de poids et de compatibilité avec les outils Slitaz qui eux utilisent sh ?
    Est-ce que cela signifie d'installer les coreutils de gnu et autres tar, sed, etc. ou est-ce qu'en bash nous pouvons utiliser certains des outils de busybox ?
    (toolchain installe bash et coreutils mais pas la totalité des utilitaires GNU)
    Dans des textes en français, il m'arrive d'avoir des caractères manquant (notamment dans des emails avec claws-mail), est-ce lié au fait d'utiliser une la locale latin1 ou à l'absence de ces caractères dans les fonts ?
    L'encodage des noms de fichiers dans Trisquel (basé sur Debian et Ubuntu) et dans Slitaz semble incompatible : les noms de fichiers encodés dans l'un affiche des erreurs dans l'autre. Pourquoi ?

    Je te remercie d'avance pour tes réponses.
    Go Khla Yeh
  • LuXLuX January 2010
    Bonjour Gokhlayeh,

    * Gokhlayeh a écrit
    Je voulais te signaler l'existence du terminal vte

    Excellent ! Le support de l'unicode par vte dans Slitaz est identique à celui de Terminal, donc très bon (affichage correct avec echo, less, cat et vim-tiny, pas avec vi mais c'est normal, et malheureusement pas avec nano (je m'étais trompé sur ce point, je me demande comment). Pour la saisie c'est toujours pareil : saisie OK mais bug à l'effacement par BackSpace, sauf si on utilise bash.

    J'ai oublié de le mentionner dans mon post initial, mais certains caractères UTF-8 moins courants que les caractères accentués sont plus larges que d'autres, même dans les fontes fixed (je pense à certains symboles mathématiques, comme les flèches longues). Terminal et vte sont capables d'afficher ces symboles correctement alors que uxterm les remplace par des carrés. Cela dit ça peut venir de la fonte employée, mais je les ai testés avec la fonte par défaut, et il me semble que c'était la même pour vte et uxterm.

    Enfin, comme pour Terminal, lancer vte à partir de la ligne de commande ne provoque aucun message d'erreur, alors que lancer uxterm produit : 
    tux@slitaz:~$ uxterm &
    [1] 1502
    tux@slitaz:~$ Warning: locale not supported by Xlib, locale set to C

    Donc vte et Terminal semblent kif-kif, avec cette différence notable que Terminal a une lourde dépendance à perl. Maintenant Terminal offre quand même d'autres fonctionnalités comme des menus et des onglets. C'est là où ta seconde indication m'intéresse particulièrement.
    * Gokhlayeh a écrit
    J'ai aussi une recette pour compiler lxterminal avec tazwok

    Merci pour la recette, mais je ne sais pas utiliser tazwok (et encore moins compiler moi-même à partir des sources). Je n'ai pas non plus accès à lxterminal dans mon Ubuntu, car j'en suis resté à Hardy. Dommage, car la description de lxterminal semble parfaitement semblable à celle de Terminal (menus et onglets) et s'il est basé sur vte on peut espérer qu'il supporte aussi bien l'unicode. J'aurais donc bien aimé l'essayer...
    * Gokhlayeh a écrit
    Qu'implique d'intégrer bash comme shell par défaut en terme de poids et de compatibilité avec les outils Slitaz qui eux utilisent sh ?

    J'aurais du mal à te répondre, à part pour le poids mais il faudrait que je reparte d'un slitaz-xorg vierge et je manque de temps tout de suite. On trouve quand même ici l'inforamtion suivante, pas forcément fiable mais qui donne quand même une indication :
    bash
        4.0
        The GNU bourne SHell.
        400.0k (840.0k installed)

    Lorsqu'on installe bash, il me semble que tazpkg propose que "sh" (ou "ash", je ne sais plus) pointe désormais vers bash, offre que je décline toujours. Du coup /bin/sh continue d'exister et de pointer vers busybox, donc je ne vois pas pourquoi ça introduirait une incompatibilité.
    Quand je parlais de faire de bash le shell par défaut des utilisateurs, c'est de l'information contenue dans le fichier /etc/passwd que je parlais, pas des scripts de Slitaz.
    * Gokhlayeh a écrit
    Est-ce que cela signifie d'installer les coreutils de gnu et autres tar, sed, etc. ou est-ce qu'en bash nous pouvons utiliser certains des outils de busybox ?

    Là aussi la question est un peu technique pour moi, mais j'ai bien l'impression que ça n'implique pas ce que tu dis. Ce que je peux dire avec certitude c'est qu'après avoir installé bash, dans mon répertoire /bin presque tout continue à pointer vers busybox. Les seules exceptions sont busybox lui-même, bash et bashbug, bootlog, extlinux, ntfs-3g et syslinux. En particulier les programmes que tu cites (cat, tar, sed...) sont encore des pointeurs vers busybox (et "which sed", par exemple, me réponds bien /bin/sed). Est-ce que ça réponds à ta question ?
    * Gokhlayeh a écrit
    Dans des textes en français, il m'arrive d'avoir des caractères manquant (notamment dans des emails avec claws-mail), est-ce lié au fait d'utiliser une la locale latin1 ou à l'absence de ces caractères dans les fonts ?

    À mon humble avis... les deux.
    - D'une part bien entendu si ta fonte ne possède pas tel ou tel caractère il sera le plus souvent remplacé par un carré.
    - D'autre part, comme je le disais plus haut, certains caractères "larges" s'affichent ou ont remplacés par des carrés selon le terminal utilisé (apparemment avec la même fonte).
    - Mais surtout quel que soit l'encodage par défaut de ton système, un fichier de texte ayant un encodage mixte (c'est-à-dire contenant des phrases en latin1 et d'autres en utf-8) ne sera jamais affiché correctement. On peut produire un tel texte facilement : part d'un fichier en latin1, convertit-le en utf-8 avec iconv et concatène les deux avec cat, et le tour est joué. Dans les courriels il arrive fréquemment qu'on ait des mélanges d'encodages, parce qu'on cite d'autres messages (un bon courrieleur devrait savoir faire cela sans se tromper, mais...) ou encore par l'ajout automatique d'une signature.
    * Gokhlayeh a écrit
    L'encodage des noms de fichiers dans Trisquel (basé sur Debian et Ubuntu) et dans Slitaz semble incompatible : les noms de fichiers encodés dans l'un affiche des erreurs dans l'autre. Pourquoi ?


    Je ne connais pas Trisquel. Personnellement je n'ai pas de problème pour mes fichiers partagés entre Ubuntu et Slitaz, tant que les deux sont en UTF-8. Bien entendu un fichier dont le nom est en UTF-8 verra ce nom mal affiché dans Slitaz en Latin1. Toutefois il y a une solution simple à ce problème, soit en convertissant une fois pour toute les noms de fichiers (le programme convmv fait ça et ne touche pas au contenu des fichiers) soit en modifiant la variable G_FILENAME_ENCODING dans le /etc/profile de Slitaz, voir à ce sujet l'excellent wiki de Pankso sur l'UTF-8, section "Glib".

    Cordialement,
    LuX.


  • GokhlayehGokhlayeh January 2010
    Merci pour tes réponses, je pourrais faire quelques recherches sur le sujet un peu plus tard grâce à toutes tes indications. Ca n'a pas l'air très simple :). En attendant, je t'explique comment utiliser la recette avec le wok :

    (toute les commandes doivent être saisies avec l'utilisateur root)

    ## Installer slitaz-toolchain qui contient le wok
     ## et les outils nécéssaires :
    tazpkg get-install slitaz-toolchain
    ## Créer un répertoire pour le wok :
    ## mkdir /home/slitaz
    ## (si tu n'as pas déjà ce dossier sur ton système)
    mkdir /home/slitaz/wok
    ## Créer un dossier et un fichier type pour
    ## une nouvelle recette :
    tazwok new-tree lxterminal
    leafpad /home/slitaz/wok/lxterminal/receipt

    Tu peux ouvrir le fichier /home/slitaz/wok/lxterminal/receipt. C'est un fichier type qu'il faut remplir avec les bonnes informations, pour que la commande tazwok cook package puisse automatiquement cuisiner le paquet. En le comparant avec la recette que je te donne tu verras que c'est finalement assez simple pour des programmes comme celui-ci :)

    Colles la recette dans leafpad et sauvegardes. Tout est prêt, il ne te reste plus qu'à entrer (toujours en tant que root) :
    tazwok cook lxterminal

    Et pour installer le paquet :
    tazpkg install /home/slitaz/packages/lxterminal-0.1.6.tazpkg


    Si tu rencontres une erreur pendant la compilation ou quand tu lances le programme, c'est que j'ai oublié une dépendance (ligne DEPENDS) ou une dépendance de compilation (ligne BUILD_DEPENDS). N'hésites pas à m'envoyer l'erreur, je corrigerais la recette.
  • panksopankso February 2010
    @LuX

    Test voir: localedef -i fr_FR -c -f UTF-8 /usr/lib/locale/fr_FR

    La locale sera ensuite "supported" par Xlib.

    Note: je vais commiter les changements qu'il faut pour avoir SliTaz en UTF-8 par défault et faire une ISO, ça sera donc prêt pour la 3.0!
  • LuXLuX February 2010
    Bonjour,

    @Gokhlayeh : Je suis reparti d'une slitaz-xorg "vierge" (j'ai juste rajouté le driver dont j'avais besoin pour la carte graphique) et l'installation de bash-4.0 a ajouté deux fichiers : /bin/bash (1142k) et /var/cache/tazpkg/bash-4.0.tazpkg (328k). Rien d'autre.

    Je n'ai pas encore pu tester ta recette car je n'arrive pas à installer gcc faute de place dans ma partition.

    @Pankso : J'ai essayé à partir de cette nouvelle installation (après avoir ajouté le paquet glibc-locale) la commande que tu as indiquée, sans changement.

    J'ai d'abord fait une erreur de copié-collé (ah, les retours à la ligne automatiques...) :
    localedef -i fr_FR -c -f UTF-8 /usr/lib/locale

    C'est seulement ensuite que j'ai tapé :
    localedef -i fr_FR -c -f UTF-8 /usr/lib/locale/fr_FR
    .
    Ça n'a pas produit de nouveau message d'erreur, mais n'a pas rien changé de visible. Exemple :
    root@slitaz:/home/tux# localedef -i fr_FR -c -f UTF-8 /usr/lib/locale
    root@slitaz:/home/tux# locale -a
    locale: Cannot set LC_CTYPE to default locale: No such file or directory
    locale: Cannot set LC_MESSAGES to default locale: No such file or directory
    locale: Cannot set LC_COLLATE to default locale: No such file or directory
    C
    POSIX
    de_DE
    es_ES
    fr_FR
    pt_BR


    Par contre la commande :
    localedef -i fr_FR -c -f UTF-8 /usr/lib/locale/fr_FR.UTF-8

    que j'avais déjà faite dans l'installation précédente améliore significativement les choses, mais ni plus ni moins que précédemment :
    - les commandes "locale -a" ou "leafpad" ne produisent plus d'erreur ;
    - uxterm supporte relativement bien l'unicode avant cette commande, mais significativement mieux après (cf mon post initial) modulo le probléme de l'effacement des caractères accentués dans la ligne de commande, que j'ai déjà rapporté et qui était toujours présent ;
    - vte-terminal, tout comme Terminal, supporte mal l'unicode avant cette commande (les carractères accentués sont remplacés par des ??) mais très bien après (sauf avec nano et vi, et toujours modulo le problème d'effacement) ;
    - beaucoup d'applications (y compris uxterm, mais pas vte-terminal) produisent quand même quand on les lance par la ligne de commande un message d'erreur selon lequel la locale n'est pas supportée par Xlib.

    NB1 : Bizarrement, nano affiche correctement un fichier unicode dans uxterm AVANT l'installation de la locale par localedef, et c'est seulement ensuite qu'il ne l'affiche plus correctement. Réinstaller nano (à coup de tazpkg ... --forced) n'y change rien.

    NB2 : Dans la saveur UTF-8 réalisée l'an dernier par asimo, et qui est encore installée dans mon portable, urxvt fonctionne parfaitement, ainsi que nano (seul le problème de l'effacement des caractères accentué est encore présent). Il n'y a pas de message de locale non supportée. Ce serait peut-être intéressant de lui demander comment il avait obtenu ça, non ? Il a proposé une mise à jour de sa saveur sur le nouveau forum (que je n'ai pas testée car d'après lui elle n'est plus compatible avec les nouveaux paquets), voir :
    http://forum.slitaz.org/index.php/discussion/303/utf-8-flavor

    Cordialement,
    LuX.
  • LuXLuX February 2010
    Bonjour Go Khla Yeh,

    tout d'abord un grand merci pour tes explications détaillées sur le wok. J'ai essayé d'appliquer te recette, et même de la modifier un peu. Ça ne marche pas encore, mais puisque que tu m'y invites je rapporte ici mes petites aventures. Ou plutôt, puisqu'il s'agit d'un autre sujet, je vais de ce pas ouvrir une nouvelle discussion ici :
    http://forum.slitaz.org/index.php/discussion/524/lxterminal/

    Cordialement,
    LuX.
  • GokhlayehGokhlayeh February 2010
    Bonjour LuX, j'ai fais quelques test suite à dernier post :
    http://forum.slitaz.org/index.php/discussion/538/insufficient-utf-8-support-was-detected-in-your-curses-and-or-c-libraries/#Item_2

    Je continue la discussion ici pour plus de facilité.
    Donc, j'ai passé mon système en UTF-8 comme cela :
    j'ajoute lang=fr_FR.UTF-8 kmap=fr-latin1 à Grub
    tazpkg get-install glibc-locale
    localedef -i fr_FR -c -f UTF-8 /usr/lib/locale/fr_FR.UTF-8


    J'ai ensuite fais des tests avec lxterminal, leafpad et nano recompilé comme je l'ai expliqué dans ton autre post.

    Premier test, lancer leafpad, faire enregistrer sous et voir quel est la locale courante selon lui :
    Depuis xterm, lxterminal : UTF-8
    Depuis le lanceur d'E17 et pcmanfm (clic-droit, nouveau fichier, l'ouvrir puis regarder la locale courante dans enregistrer sous) : latin-1

    Je suis allé dans la configuration d'E17 pour séléctionner la locale FR_fr.utf8, ça a réglé le problème du lanceur. Pour pcmanfm je suppose qu'il faut le configurer mais je ne sais pas comment.

    Deuxième test, ouvrir un fichier UTF-8 avec nano (version recompilée) :
    Lancer nano depuis xterm : problème d'affichage de caractères
    Lancer nano depuis lxterminal : les caractères s'affichent correctement

    J'ai essayé d'installer readline mais il était déjà présent.
    Affichage du message d'erreur dans xterm :
    tazpkg get-install readline

    readline est déjà installé. Vous pouvez utiliser l'option --forced pour
    forcer l'installation ou supprimer le paquet et le réinstaller.

    Affichage du message d'erreur dans lxterminal :
    tazpkg get-install readline 

    readline est d�j� install�. Vous pouvez utiliser l'option --forced pour
    forcer l'installation ou supprimer le paquet et le r�installer.


    Je suppose que le message envoyé par tazpkg n'est pas encodé en UTF-8 mais en latin-1 ce qui provoquerais cette erreur. Si je fais
    echo é

    dans lxterminal il m'affiche le caractère correctement.
    Si je fais
    echo -n é | wc -c

    J'obtiens 2.

    Suite à la réponse de pankso sur l'autre post je vais tenter de recompiler vte et lxterminal avec le ncurses qui supporte l'utf-8

    --Edit
    C'est fait mais je ne remarque pas de différence notable pour le moment.
  • LuXLuX February 2010
    Bonjour Go Khla Yeh (enfin re-re-re...) !

    * Go Khla Yeh a écrit
    Donc, j'ai passé mon système en UTF-8 comme cela [...]


    Oui, c'est comme ça que j'avais fait aussi. Tes tests confirment les miens sur plusieurs points:

    - xterm ignore totalement l'UTF-8, alors que vte-terminal et les autres (uxterm, Terminal, lxterminal) le supportent plus ou moins;

    - bien que je ne l'ai pas rapporté j'avais aussi eu le genre d'affichage que tu signales en provenance de tazpkg. Dans la même veine on peut signaler le répertoire "~/Téléchargement" dont le nom sera affiché correctement dans les terminaux unicodes mais pas dans xterm ni dans... pcmanfm.

    Le fait que nano supporte l'unicode après la recompilation que tu as faite semble encourageant, mais... voir à la fin de ce message.

    Par contre je suis surpris par le comportement de leafpad. Chez moi il ne dépend pas (en tout cas plus) du point de lancement (xterm, lxterminal ou le menu du fond de l'écran). La première fois que je le lance et que je sauvegarde quelque chose il propose toujours comme encodage un machin bizarre ganre "ANSI quelque chose". Mais peut-être que c'était avant que j'applique localedef, je ne sais plus (il ne propose même plus cette option maintenant). Si je laisse cet encodage il me dit qu'en fait il n'est pas supporté, ou quelque chose du genre. Il me semble qu'à partir du moment où que j'ai sauvegardé une fois en choisissant l'UTF-8, il a toujours proposé ensuite l'UTF-8 par défaut. En tout cas c'est ce qu'il fait maintenant.

    En ce qui concerne la recompilation de ncurses et de paquets qui en dépendent, j'ai posté mes remarques sur le forum anglophone :
    http://forum.slitaz.org/index.php/discussion/comment/2587/#Comment_2587
    En résumé : à mon avis avant de recompiler autre chose il faut corriger encore la recette de ncurses.

    Bien cordialement,
    LuX.
Add a Comment

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

Categories

SliTaz Network

SliTaz Social