| Re: [CBLX] Utiliser brltty sans plage braille |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/carrefourblinux Archives
]
Salut
Voilà une discussion qui me semble-t-il s'engage sur de bonnes
bases. Tu pointes bien les endroits où il y a des difficultés :
From: coolbrother@xxxxxxxxxx
Subject: Re: [CBLX] Utiliser brltty sans plage braille
Date: Thu, 5 Mar 2009 01:19:46 +0100 (CET)
> Salut Pierre, tu m'fais rire, j'avoue que ça m'es passé par la tête.
> Mais très intéressants tes conseils de papi dans ton mail précédent,
> je cherchais ça.
Eh ben come quoi parfois faut quand-même un peu faire le
vieux c..
> Mon point de vue de jeunesse qui ne demande qu'à être élargi, c'est
> que brltty et speakup prend en charge le dv depuis l'installation du systeme,
> en passant par le login, jusqu'à l'arrêt du systeme.
Oui enfin brltty est lancé très tôt mais c'est
relatif. Typiquement brltty doit être lancé après udev, et
donc après que le noyau ait complètement booté. Si donc tu as
une ereur noyau comme j'en ai eu récemment brltty, speakup et
les autres sont tous aussi inefficaces. Le point clef est
q'une synthèse vocale logiciel est déjà un programme de
niveau assez élevé et que son lancement implique donc que des
routines de bas niveau soient totalement fonctionnelles. Si
donc tu as un bug dans lesdites routines de bas niveau :
tintin ! Donc tu progresses un peu vers le big bang mais le
mur de Planck est toujours là ! Bon les astrophysiciens sont
très contents en général d'avancer d'un milliardième de
seconde vers le mur alors pourquoi pas nous ?
> Et les deux sont fidèles au bash.
> Tandis que emacs vient après le login, et ne permet pas de tester toute
> appli non adapté pour emacs.
Euh ça pourquoi ? Quelle différence entre brltty sonore,
speakup et le mode shell d'emacs qui n'est rien d'autre qu'un
lecteur décran ?
> Venant du développement sur win$ je pense que emacs c'est bien pour
> l'utilisateur lamda, mais pour des taches administratives,
> test etc.. il manque à linux un vrai lecteur d'écran, qui est
> déjà bien
Erreur ! J'ai fait de l'admin système sous emacspeak pendant
des années. Et Raman à mon avis aussi. Et si tu me dis que
Raman est un utilisateur lambda .... Hum là je vais être
obligé de ne pas être d'accord.
Pour tout dire je comprends parfaitement ta réaction pour la
simple et bone raison que je l'ai eue moi-même en mon
temps. Je venais de dos où on avait des lecteurs d'écran
certes rudimentaires (le légendaire sonolect) mais qui
donnaient accès à rigoureusement tout le contenu de
l'écran. En passant sous emacspeak qui était alors la seule
solution d'accessibilité gratuite à l'époque (je n'avais pas
les moyens de me payer une plage braille) je pensais être
coupé d'une partie du système et avoir toujours un rideau de
fumée entre moi et les couches profondes du système. Et bien
l'expérience m'a prouvé que non. Bash est aussi une couche
entre toi et les profondeurs du système. On a l'impression
que bash est plus transparente qu'emacs. Et bien là aussi je
pense que c'est une illusion mais que pour s'en défaire il
faut pratiquer.
Cela dit ce serait bien que tu sois un peu plus précis et que
tu pointes les tâches particulières qui ne te semblent pas
faisables sous emacs.
Bon on a déjà listé la phase antérieur au login et le login
lui-même. Là brltty peu dans sa forme actuelle suppléer.
Plus précisément qu'y a-t-il dans cette phase :
Des messages qui apparaîssent et signalent l'état
d'avancement du boot. Brltty ou speakup peuvent parfaitement
les sonoriser. Si le boot va au bout (ah le superbe jeu de
mot que voilà) en fait tout ce bazar est dans dmesg qu'on
peut parfaitement consulter ensuite sous emacs.
S'il y a une erreur, effectivement ça vaut le coup de pouvoir
s'en apercevoir. Mais je te rappelle que seules les erreurs
intervenant après brltty donc après udev, donc après
chargement complet du noyau seront accessible par ce
biais. Des trucs somme toute alors assez subalternes.
Enfin il y a le login lui-même où il peut être intéressant de
contrôler qu'on tape bien son login mais juste son login
parce que le passwd de toute façon lui il n'apparaît pas.
Alors développer tout un bazar pour les huit ou dix lettres
du login ... Moi ça ne m'embale pas personnellement.
Dans mon bureau j'ai juste la synthèse. Donc j'ai mis un
petit script en fin de boot qui fait dire à speech-dispatcher
que le boot est complet et qu'on peu se loguer. Ensuite je
lance emacs dans mon .bashrc donc dès que j'ai tapé le login
et le passwd je suis en sonore.
> lancé avec brltty
> et speakup. Mais, c'est un long débat qui demande plus de
> mails.
Certes ! mais je suis tout à fait prêts à débattre de ça avec
toi et espérons-le de la manière la plus sereine possible.
Résumé pour moi :
Analyse : Les outils d'accessibilité démarrent à un instant t
différent (et même strictement supérieur) de l'instant 0 du
big bang du système. brltty ou speakup démarrent plus tôt
qu'emacs.
Voilà l'analyse. En es tu d'accord.
Conséquence : Certaines tâches sont accessibles par brltty ou
speakup qui ne le sont pas par emacs.
- Des tâches prélogin : OK mais de mon point de vue pas tant
que ça et les outils susnommés dans leur état actuel
(brltty sans plage braille par exemple) permettent déjà de
compenser : donc pas grand chose à faire.
- Des tâches post-logi : C'est là sans doute que nous
divergeons le plus mais j'aimerais justement creuser avec
toi cette question et être sûr que de ton point de vue
comme du mien elle ne procède pas d'une méconnaissance
d'emacs plutôt que de réelles impossibilités de ce
derniers. Si tu me pointes des situations où emacs est
réellement inopérant je suis prêt à reconsidérer
complètement la question.
à suivre !
Pierre
---
--
CarrefourBLinuX MailingListe
Pour obtenir de l'aide, envoyez le sujet help à:
carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
Archives:
http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux