Salut Raphaël,
From: Raphaël POITEVIN <[EMAIL PROTECTED]>
Subject: Re: [CBLX] Lecteur d'ecran en console
Date: Sun, 17 Aug 2008 17:28:54 +0200
> Bonjour Pierre,
> ---- Original Message -----
> From: "Pierre Lorenzon" <[EMAIL PROTECTED]>
> To: <carrefourblinux@lists.freearchive.org>; <[EMAIL PROTECTED]>
> Sent: Friday, August 15, 2008 3:27 PM
> Subject: Re: [CBLX] Lecteur d'ecran en console
>
>
> > From: [EMAIL PROTECTED]
> > Subject: [CBLX] Lecteur d'ecran en console
> > Date: Fri, 15 Aug 2008 12:46:42 +0200 (CEST)
> >
> >> Bonjour, qui utilise un lecteur d'écran vocal en console ?
> >
> > À mon avis pas grand monde. Et tout simplement parce qu'il
> > faudrait avoir de bonne raisons de faire ça. Mon opinion
> > c'est que c'est rigoureusement impraticable pour utiliser des
> > applis. Ca se justifierait à la limite pour des opérations de
> > maintenance système de très bas niveau et si on n'a pas de
> > braille. Sans quoi, lesdites opérations se font plus aisément
> > avec un afficheur braille. Pour de l'utilisation courante, il
> > faut selon moi utiliser des environnements intégrés : deux
> > philosophies alors : emacs+speechd-el ou apparenté ou gnome+
> > orca.
> Excuses-moi Pierre, mais tu es là pour me persuader et je suis sûr que tu
> vas finir par y arriver car j'ai beaucoup de mal à me faire à l'idée de me
> calfeutrer dans un environnement dit "fermé" comme Emacs, meme si tu jures
> que ça ne l'est pas. J'avoue ne pas avoir eu le temps encore de m'y mettre
> mais ça va venir. Cependant, il y a des choses qui me
> chifonnent lorsqu'on
Rassure-toi Raphaël, j'ai eu la même réaction que toi quand
je suis arrivé à Linux : et pour cause je venais du dos où
j'avais l'impression de pouvoir tout contrôler à travers
sonolect, et philosophiquement ça me gênait de voir emacs
m'"écranter" le système. Jusqu'au jour où j'ai compris que
sous emacs on ne se calfeutre pas mais qu'au contraire on
s'ouvre des horizons.
Il faut distinguer suivant le niveau avec lequel on interagit
avec le système. Pourquoi s'évertuer à faire indéfiniment un
ls -al en console et à se débrouiller comme on peut pour lire
la sortie, (ce qui devient une vraie galère si elle dépasse
un écran) plutôt que d'utiliser m-x dired sous emacs dont la
sortie est rigoureusement la même que celle de ls -al sauf
qu'on peut naviguer dedans (avec écho sonore grâce à
speech-el) et éventuellement utiliser les possibilités du
file manager.
Si vraiment on a l'impression qu'emacs nous cache quelque
chose (et je crois que c'est ça, le fond de l'affaire, on
aurait l'impression qu'emacs fait des choses pour nous alors
qu'on est bien assez grand pour les faire) et bien reste
toujours le M-x shell qui ouvre un buffer shell dans lequel
on est exactement comme dans la console sauf que c'est
sonore. On s'apperçoit à termes qu'il est bien plus efficace
d'utiliser, quand elle existe, la surcouche emacs prévue pour
piloter l'application qu'on a en vue. En fait les concepteurs
de ces interfaces jouent rarement à dissimuler : il
restituent peu ou prou l'output de la commande mais en
donnant au texte des "properties" (dans le jargon emacs) qui
permettent de déclencher un certain nombre d'actions
lorsque on fait return sur une portion du texte.
> veut utiliser d'autres softs que Emacs n'intègre pas comment fait-on ? Par
> exemple, un logiciel pour écouter du son qui n'a pas l'air d'exister même si
> tu y travailles, un logiciel de conversation sur internet, un logiciel de
> voix sur IP et j'en passe. Pour le moment, j'avoue pour le
> peu de choses que
D'abord, il y a un certain nombre de choses qu'emacs intègre
et il serait à mon avis dommage de se priver de
celles-là. Pour celles qu'il n'intègre pas, M-x shell ne sera
sans doute pas pire que yasr. Il y a un certain nombre
d'applis pour lesquelles il faut effectivement encore &écrire
des interfaces.
Pour le son tu peux utiliser un play, aplay standard. Le plus
simple c'est d'ouvrir le file manager d'emacs : M-x dired
<nom du dir> <ret> (ou C-x d) de placer le curseur sur le
fichier que tu veux jouer et de faire M-! on te demande le
nom de la commande à exécuter et là tu entres ton player
favoris : play, aplay ou que sais-je. Problème, c'est en mode
synchrone donc emacs n'est plus utilisable tant que tu n'as
pas interrompu le programme (avec C-g par ex) ou qu'il n'est
pas terminé. Cela dit si tu veux le faire jouer en mode
asynchrone et faire du java avec (euh je ne sais pas ce que
tu écoutes) dans les oreilles, je peux te faire les 4 lignes
de code pour faire ça :
(defvar player "alsaplayer"
"Nom de l'exécutable à utiliser")
(defun play ()
(interactive)
(start-process "Play"
nil
player
(dired-get-file-for-visit)))
Tu vas dans le répertoire où est ton fichier à jouer, tu mets
le curseur sur la ligne où est le fichier que tu veux jouer et
tu fais M-x play et c'et polié !
Tu as là une réponse à une de tes questions ultérieures : vas
t'en demander à bash après avoir fait un ls quel est le fichier
sur la ligne où se trouve le curseur ... Emacs est ainsi fait
que le langage de programmation est bourré de routines qui te
permettent grosso-modo d'interroger emacs sur ce qu'il fait, ce
qu'il a fait (et n'exagérons rien mais dans une certaine mesure
ce qu'il va faire.) Note que je crois que gnome est
suffisamment bien conçu pour que ce soit à peu près pareil.
> je fais, c'est-à-dire de la découverte avec mes vieilles habitudes du dos,
> n'utiliser que la console et ne pas passer par Emacs même si ça me dérrange
> de nepas avoir le vocal pour travailler à toutes vitesse comme je le fais
> d'habitude.
Ben essaye au moins le emacs plus M-x shell tu auras au moins
une console vocale brute de décoffrage.
> >
> > Oui on l'a fait par le passé, sonolect n'était rien d'autre
> > qu'un lecteur d'écran en console sous dos mais quand on songe
> > aux acrobaties qu'il fallait faire pour fabriquer des modules
> > qui pilotent plus ou moins bien les applis qu'on voulait
> > utiliser on est content du confort qu'on a aujourd'hui en
> > passant par des intégrateurs de tâches.
> Et on aurait pas ce problème de sonorisation avec Emacs pour utiliser un
> autre logiciel ? Il ne me semblait pas si complexe d'écrire un fichier pour
> sonoact mis à part un coût en temps. Bon tu vas me dire que je mélange tout
> et ça ... c'est certainement vrai.
Non je t'ai expliqué plus haut que quand emacs lance un
sous-process (la méthode pour contrôler une appli) il garde
un contrôle très serré sur les flux entrant et sortant à tout
le moins. avec une fonction comme start-process qui permet
par exemple de filtrer les entrées et les sorties.
>
> Concernant YASR, d'après toi ça serait une solution au pied levé ? Ca ne
> vaudrait pas le coup de s'y pencher un peu pour voir ?
Moi en tout cas je ne me pencherai pas: je resterai "droit
dans mes bottes!" Bah psychorigide diront certains ! Mon
opinion est que yasr ne fera jamais mieux que le M-x shell
sous emacs et ça c'est ce qu'on a de pire sous emacs : moralité
le mieux de yasr ne sera jamais que le pire d'emacs.Euh euh,
il faut savoir raison garder, si on doit faire de l'admin
système sans braille, on est peut-être obligé d'avoir recours
à des trucs comme yasr plus économiques qu'emacs. Lorsque
j'installe une linux from scratch je ne peux avoir emacs qu'à
la fin de la phase de base : le début ça se fait avec
brltty. J'avoue que là ça pourrait être délicat d'être dans
un shell qu'on ne contrôle pas dans le moindre détail : une
variable d'environnement de travers et tout est par terre.
> >
> > Petit point d'histoire qu'il est toujours important de
> > rappeler, et dont je dois faire mention au moins une fois par
> > mois sur cette liste : si Raman a choisi de sonoriser emacs
> > et pas bash c'est qu'il y avait, et qu'il y a toujours de
> > bonnes raisons à ça. Il est techniquement très difficile
> > d'interagir avec bash alors que c'est un jeu d'enfant avec
> > emacs et qu'apparemment ça n'est pas si compliqué que ça sous
> > gnome.
> Et pourquoi est-il difficile d'interragire avec bash ?
Parce que le langage est horrible ! Bon ça c'est peut-être un
avis personnel: et puis ça n'est pas la vrai question : non
c'est juste qu'il est trivial d'interagir avec emacs. On peut
se glisser sans difficulté dans la main loop et réagir à peu
près à chaque changement de l'environnement qu'emacs vous
signale gentiment. C'est comme ça qu'est fait speechd-el par
exemple. Il y a d'autres mecanismes subtiles comme le fait
d'"adviser" une fonction qui consiste essentiellement à
l'embaler dans un morceau de code sans la modifier : pour la
maintenance c'est tout bénef si la fonction change un peu
(pas trop bien sûr) l'embalage peut rester valable. Et puis
dernier point et non des moindres, tout ça est fait dans le
langage d'emacs et pas dans le code du moteur principal. Donc
pas besoin de recompilations aussi douteuses que coûteuses
pour que ça marche.
Et puis rien ne vaut ce que les concepteurs d'emacs disent de
lui : "Emacs is the extensible, customizable, self-documenting real-time
display editor. " Et moi qui le pratique depuis près de 10 ans
maintenant, je dis que ce n'est pas que de la pub !
Pierre
_______________________________________________
Liste de diffusion CarrefourBLinuX
CarrefourBLinuX@lists.freearchive.org
http://lists.freearchive.org/mailman/listinfo/carrefourblinux
Pour s'inscrire par courriel :
'mailto:[EMAIL PROTECTED]'
Pour se retirer de la liste par courriel :
'mailto:[EMAIL PROTECTED]'
Archives : http://lists.freearchive.org/pipermail//carrefourblinux
Anciennes archives (Yahoogroupes) :
http://fr.groups.yahoo.com/group/carrefourblinux/messages
Rechercher : http://lists.freearchive.org/cgi-bin/search.cgi
Signets : http://fr.groups.yahoo.com/group/carrefourblinux/links/
Fiches EDU : http://blinuxwiki.pbwiki.com/FichesEdu
