| Re: Environnement(s) sonore Was: Re: [CBLX] Du nouveau sur Speakup ? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/carrefourblinux Archives
]
Salut Pierre,
>> (inter-console), avec un gestionnaire de clavier complet,
>> comme Ctrl+Insert+G.
>
> Pourquoi interconsole ? À quoi ça sert ? Bash n'est pas
> interconsole et tout le monde est content avec bash. Le seul
>
Venant d'un environment essentiellement graphique (win$), je pense qu'il y a de
bonnes choses à récupérer et d'autres à laisser et surtout à ne pas y
toucher.
Mais sur ce qu'il y a à récupérer, il y a la notion du presse-papier,
qui me paraît essentiel d'où le besoin d'inter-console.
Bien sûr si l'on reste que dans emacs, il n'est pas nécessaire
d'utiliser un presse-papier. Mais je n'en suis pas encore là. Dans mon
esprit, tout déficient visuel devrait utiliser l'application de son
choix et pouvoir transférer des données d'une appli à l'autre les doigts
dans le nez.
C'est un problème qui m'a beaucoup géné en arrivant sur linux.
Vu qu'une grande partie de mon travail consiste à faire de la
veille sur internet: naviguer, rechercher, sauvegarder, modifier ...
j'avais vraiment besoin de passer des données de w3m à Vim.
Tu m'avais gentilment proposé de résoudre ce problème avec emacs, mais
psychologiquement je ne partage pas l'idée de tout réaliser à partir d'une
seule application. Et puis c'est avec Vim que j'ai commencé, et donc je
m'en suis fait et fini par l'aimé, donc difficil de m'en défaire. Mais
ce sont-là ique des raisons personnelles. Je ne suis pas fermé, je ne
demande qu'à apprendre, et si après des tests concluants, emacs
se révèle être le mieux pour une meilleure accessibilité plutôt qu'un
lecteur d'écran, pas de problème, je fonce car pour moi l'intérêt commun
passe avant tout.
Finalement j'ai réussi à résoudre ce problème de presse-papier, et j'en
profite pour poster la manipe ici pour d'autres qui chercheraient une
solution.
Au bout de plusieurs mois, j'ai fini par comprendre que w3m permettait
d'envoyer le contenu à l'écran dans l'éditeur de son choix avec la commande Alt+e.
Puis dans vim, j'ai fait un macro très simple pour copier ce
contenu dans un fichier avec le raccourci Ctrl+c, et un autre macro pour
récupérer le contenu de ce fichier avec Ctrl+v dans une autre console..
S'il y en a qui souhaitent ces macros, no problemo, suffit de demander.
Et depuis c'est le bonheur, je suis plus efficace en utilisant les
applics que je souhaite.
Mais ce n'est pas une solution à confier à l'utilisateur lamda, "monsieur
tout l'monde", qui
débute sous linux, et qui ne demande juste iqu'à récupérer du texte sur
internet. C'est trop compliqué pour l'accessibilité.
C'est pourquoi il faut un programme inter-console pour répondre à ce
besoin de presse-papier.
> le seul hic et on en a déjà parlé c'est qu'emacs ne sonorise pas le
> login. C'est extrêmement mineur à mon avis et on peut pour le
> coup utiliser des outils rudimentaires à la speakup ou la
> partie sonore de brltty pour faire ça. Il est possible que
> quelques combinaisons de touche capturées en amont d'emacs ne
> soient pas accessibles à emacs mais elles sont extrêmement
> minoritaires.
>
Je pense que sonorisé le login n'est pas du tout mineur pour un
débutant. Le problème majeur qui se pose est que l'on arrive sur un
nouveau système avec des appréhensions, donc pas du tout en confiance,
et on nous demande de saisir des suites de caractères sans avoir un retour
sonore, donc pas le moyen de controler les fautes de frappe, si la majuscule est
vérouillée ou pas, et on ne peut savoir si le login est accepté ou pas.
Alors on peut continuer longtemps comme ça à l'aveugle.
Moi dans les débuts, j'ai tapé mon login, puis mon mot de passe, et
croyant que j'étais sur la console, j'ai tapé une commande, mais mon mot
de passe était faux, donc j'ai tapé ma commande dans le champ du login
qui s'affiche après une erreur. Puis j'ai continuer à faire des tests de
commande, et quand je me suis aperçu que je n'étais pas connecté, j'ai
essayé de retaper mon login et mon mot de passe, mais là, n'ayant pas de
retour sonore, je ne savais plus si j'étais dans le champ login ou mot
de passe.
Infernal ! Et je pense que l'on a tous connu ça. Obligé de rebooter la
machine.
L'accessibilité pour tous c'est à la fois du développement, de
l'ergonomie et aussi de la psychologie.
Et sonoriser le login a une grande importance psychologique pour le
débutant comme pour l'initié.
Car même pour moi aujourd'hui, depuis que j'ai installé speakup pour sonoriser le
login, je suis beaucoup plus libre, moins stressé pour taper mon nom
d'utilisateur et n'ai pas besoin d'une plage braille pour vérifier.
Je terminerai en disant que Speakup n'est pas un outil rudimentaire, car
je m'en sers tous les jours au boulot, souvent sans plage braille
quand il ne s'agit pas d'internet,
et qu'il est très satisfaisant quand il s'agit de lire rapidement
des documents dans n'importe quel éditeur, d'effectuer des tâches administratives en
local ou sur un autre serveur et en plus est très stable.
Et c'est encore mieux si on l'utilise avec brltty pour des recherches
pointues.
Donc un outil pas complet mais très avancé et à ma connaissance le mieux en terme de
lecteur d'écran pour console linux. Donc respect !
Aussi, le combiner à emacs pour en faire un outil d'accessibilité
complet serait un très bon choix.
Bon aller, je vais boire un coup à ta santé !
A bientôt:
Sam
> > Salut Sam,
>
>
> From: Coolbrother <coolbrother@xxxxxxxxxx>
> Subject: Re: [CBLX] Du nouveau sur Speakup ?
> Date: Tue, 30 Jun 2009 08:46:16 +0200
>
>> Salut Pierre,
>>> J'ai peur qu'on retourne sempiternellement à la même question
>>> qu'on tourne et retourne depuis des lustres : "on sonorise
>>> bash ou un autre intégrateur de tâches." En gros à cela il y
>>> a deux réponses, les environnements graphiques ou un
>>> environnement de type emacs.
>> Mais c'est bien de revenir à la meme question,
>
> Oui il est légitime de se poser des questions, même si elles
> ont déjà été posées. Il se pourrait tout à fait que le
> contexte se soit modifier de sorte que la réponse apportée à
> un instant t ne soit plus valable plus tard.
>
>
>
>> car pour celui qui pose la question, c'est toujours
>> différent.
>
> Certes, mais pas seulement : voir plus haut.
>
>
>
>> C'est bon de tourner en rond pour ne pas maltourné !
>
> Euh !
>
>
>
>
>> Toi et Sam vous etes des bons enseignants parce vous etes capables de
>> répéter mille fois les choses.
>> Et je vous permet d'etre des bons professeurs parce que je vous pose
>> mille fois
>> la meme question jusqu'à ce que j'ai trouvé ma réponse.
>> Réponse d'ailleurs que vous n'avez pas, mais que vous m'aider à trouver.
>> Donc ne refuse pas le cercle, vu que tout est cycle.
>
> Bon ! Admettons !
>
>
>
>> Tout ça pour dire d'apres la réponse de Sam, en espace utilisateur,
>> il ne reste plus que emacs qui se rapproche le plus d'un lecteur d'écran
>> mature et programable.
>
> Mature et programmable c'est indiscutable et indéniable ! et
> ce sont même ses qualités les plus significatives. Le bémol
> est le terme lecteur d'écran. Cela dit comme la définition
> même de ce terme est floue je n'ai pas très envie de gloser à
> l'infini sur ce mot. La question c'est qu'il faudrait plutôt
> avoir un mini cahier des charges pour l'outil de tes rêves
> afin de déterminer si oui ou non emacs et ses extensions
> sonores peuvent faire l'affaire. Il y a une ébauche
> ci-dessous et c'est ça que j'apprécie dans ta
> démarche. Personnellement j'emploierais plutôt le terme
> d'"intégrateur de tâche sonore" mais bon.
>
>
>
>
>> Mais dans ce cas-là, il faudrait épuré emacs de tout le non nécessaire
>> pour un
>> lecteur d'écran, y compris l'éditeur, et garder que son API à inter-agir
>> avec les autres logiciels ou le bash.
>
> Hum ! qui peut le plus peut le moins ! les features d'emacs
> sont disponibles on peut les activer ou non. Et ce d'autant
> plus souplement que la plupart desdites features sont dans
> des librairies lisp qui ne sont chargées que si besoin. La
> fonction même d'éditeur n'est qu'une fonction parmi
> d'autres. C'est celle qu'on connaît parce qu'emacs se lance
> en mode éditeur. Et ça d'ailleurs ce n'est même pas vrai le
> mode par défaut c'est le mode du buffer scratch qui est en
> lisp evaluation.
>
>
>
>> Et tout ça en arriere-plan. Et en plus il faudrait qu'il soit
>> inter-session,
> Non ! C'est là que tu fais fausse route parce que la
> philosophie d'emacs t'échappe peut-être encore un peu. Emacs
> ne sera ni plus ni moins en arrière plan que bash si tu
> veux. C'est un shell c'est-à-dire mot à mot une coquille qui
> embale l'utilisateur d'un côté et les applis de l'autre.
>
> L'objet de base sous emacs est le buffer. Au buffer est
> associé un mode c'est-à-dire une manière d'interagir avec les
> autres composantes du système. Ainsi les échos clavier
> peuvent être capturés et analysés. Les output d'une appli
> lancé comme sous process également.
>
>
>
>> (inter-console), avec un gestionnaire de clavier complet,
>> comme Ctrl+Insert+G.
>
> Pourquoi interconsole ? À quoi ça sert ? Bash n'est pas
> interconsole et tout le monde est content avec bash. Le seul
> hic et on en a déjà parlé c'est qu'emacs ne sonorise pas le
> login. C'est extrêmement mineur à mon avis et on peut pour le
> coup utiliser des outils rudimentaires à la speakup ou la
> partie sonore de brltty pour faire ça. Il est possible que
> quelques combinaisons de touche capturées en amont d'emacs ne
> soient pas accessibles à emacs mais elles sont extrêmement
> minoritaires.
>
>
>> Est-ce que emacs répond à ses critères très spécifiques
>> qui apparemment ne se gère qu'au niveau du noyau ?
>
> Mais ces critères sont-ils vraiement indispensables ? Il me
> semble qu'il y a encore un pas à franchir. Il me semble que
> dans ton esprit il s'agit encore de programmer un lecteur
> d'écran comme tu les connais. En gros une appli qui tourne
> dans le background et qui capture tout ce qui passe et crache
> en sonore ce qui est intéressant. Et bien la question serait
> plutôt à mon avis : est-ce que emacs sait faire ça fusse dans
> un espace un peu plus restreint. Si la dite restriction de
> l'espace n'occasionnne aucune restriction des possibilités de
> l'utilisateur, c'est peut-être un peu moins satisfaisant pour
> l'esprit, mais dans le cadre de l'efficacité pratique c'est
> largement ce qu'il faut.
>
> Je crois que le centre de la discussion est vraiement là ! Ce
> dont j'essaye de te convaincre depuis le début, mais c'est un
> long processus, c'est précisément qu'emacs t'imposera des
> restrictions dans la manière de sonoriser mais qu'en
> définitive ces restrictions n'en seront pas pour
> l'utilisateur.
>
> Tu pourrais commencer par utiliser festival.el et
> ecasound.el qui sont les interfaces emacs distribuées avec
> les projets festival et ecasound et qui te permettent
> d'utiliser lesdits programmes sous emacs comme si tu les
> utilisais sous shell sauf que c'est sonore. si tu es encore
> plus courageux tu peux essayer les interfaces gap ou gp Pari
> !
>
> Essentiellement voilà ce qu'il s'agit de faire : quand tu as
> une appli que tu veux utiliser en sonore, tu fais une petite
> interface emacs qui permet de la lancer comme sous-process
> d'emacs. Exactement comme bash lance une appli en sous
> process lorsque tu tape son nom dans la console. La
> différence c'est qu'emacs te permet d'intervenir à tous les
> niveau, ceux des imputs clavier, des output programme. Ainsi
> certains input clavier peuvent être réémis comme commande
> vers le sous process tandis que d'autres peuvent être
> capturés par emacs dont il fait ce qu'il veut (typiquement te
> donner l'heure si ça t'amuse, mais ça avait l'air de
> t'amuser).
>
> Voilà j'espère avoir été assez clair mais n'hésite pas à
> demander des détails supplémentaires;
>
> Pierre
>
>
>
>>
>> A bientôt:
>> Sam
>>
>>
>>> From: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
>>> Subject: Re: [CBLX] Du nouveau sur Speakup ?
>>> Date: Fri, 26 Jun 2009 23:15:21 +0200
>>>
>>>> coolbrother@xxxxxxxxxx, le Sat 27 Jun 2009 00:08:01 +0200, a écrit :
>>>>> vu que speakup est un programme module, peut-on lui ajouter du code
>>>>> pour qu'il utilise un programme tiers utilisateur, afin d'améliorer
>>>>> ses fonctionalités ?
>>>>
>>>> Non. Enfin si c'est possible mais c'est pas terrible en terms de
>>>> conception logicielle et ça ne sera a priori pas accepté.
>>>
>>> Bien sûr je m'avance sur la pointe des pieds, parce que
>>> Samuel est bien plus au point que moi sur ce genre de
>>> questions mais ! on commence à comprendre pourquoi les gens
>>> qui ont développé des environnements sonores ont attaqué plus
>>> bas i.e. dans l'intégrateur de tâche utilisateur. Je l'ai
>>> déjà dit, pourquoi ne pas sonoriser init tant qu'on y est. Et
>>> il me semble qu'il y a une ébauche de réponse de Samuel
>>> ci-dessus : ça pose des problèmes en termes d'architecture du
>>> système et assez probablement de maintenance.
>>>
>>> J'ai peur qu'on retourne sempiternellement à la même question
>>> qu'on tourne et retourne depuis des lustres : "on sonorise
>>> bash ou un autre intégrateur de tâches." En gros à cela il y
>>> a deux réponses, les environnements graphiques ou un
>>> environnement de type emacs. Je sais que Sam ne va pas aimer
>>> l'argument d'autorité mais moi, perso, sachant que Raman a
>>> déjà tourné et retourné cettte question dans sa tête et que
>>> sa tête n'est pas si mal faite que ça ! Sachant en outre que
>>> je ne vois aucune inovation technologique majeure qui ait pu
>>> faire évoluer la situation, je considère commme raisonable de
>>> m'en tenir à ses choix.
>>>
>>> Pierre
>>>
>>>
>>>
>>>>
>>>>> Quelle est la librairie sous console, qui permet de récupérer en
>>>>> C/c++ le nom de l'application en cours, c'est-à-dire en avant-plan,
>>>>> le process Id, le texte à l'écran ?
>>>>
>>>> En fait c'est bien plus difficile à le faire dans l'espace utilisateur
>>>> que dans l'espace noyau. Je ne connais pas de librairie faisant cela,
>>>> suseblinux fait du bricolage pour le faire.
>>>>
>>>> Samuel
>>>>
>>>> ---
>>>> --
>>>> CarrefourBLinuX MailingListe
>>>> Pour obtenir de l'aide, envoyez le sujet help à:
>>>> carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
>>>> Archives:
>>>> http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux
>>>>
>>>
>>>
>>> ---
>>> --
>>> CarrefourBLinuX MailingListe
>>> Pour obtenir de l'aide, envoyez le sujet help à:
>>> carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
>>> Archives:
>>> http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux
>>>
>>>
>>
>> ---
>> --
>> CarrefourBLinuX MailingListe
>> Pour obtenir de l'aide, envoyez le sujet help à:
>> carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
>> Archives:
>> http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux
>>
>
>
> ---
> --
> CarrefourBLinuX MailingListe
> Pour obtenir de l'aide, envoyez le sujet help à:
> carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
> Archives:
> http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux
>
>
---
--
CarrefourBLinuX MailingListe
Pour obtenir de l'aide, envoyez le sujet help à:
carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
Archives:
http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux