| Re: Environnement(s) sonore Was: Re: [CBLX] Du nouveau sur Speakup ? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/carrefourblinux Archives
]
Ah tien te revoilà ! Ca va me changer du déboggage d'auctex
!!!!
From: Coolbrother <coolbrother@xxxxxxxxxx>
Subject: Re: Environnement(s) sonore Was: Re: [CBLX] Du nouveau sur Speakup ?
Date: Sun, 5 Jul 2009 15:58:39 +0200
> 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.
Question de vocabulaire et argutie légèrement jésuite, je te
l'accorde, ne considère plus emacs comme une appli mais comme
un shell ou un intégrateur de tâches et ta question est
résolue ! Est-ce que les gens voyants ou non se m=plaignent
d'utiliser bash pour ceux qui consolent et gnome/kde pour
ceux qui graphiquent ? Moi je dis, il y a un certain nombre
d'intégrateurs de tâches disponibles, et pour faire bref :
bash, gnome, kde et emacs. Je dis ensuite, à mon sens emacs
est le plus adapté d'entre eux à être sonorisé. Je ne dis ni
plus ni moins.
Quoi emacs a des fonction d'éditeur. Beh bash aussi si tu
veux bien y regarder de près, sauf que celle de bash y a pas
grand monde qui a envie de rédiger un document avec !
> 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
Ah ! C'est très psychologique en effet ! Est-ce que par
hasard tu ne réalise pas tout avec une seule et même
application qui s'appelle, enfin, cherchons un peu, linux
2.6.26 !!m! ??? Ah non 2.6.47 ! Pas encore sortie ! mais
venant de toi je m'attends à tout ! Euh ! Plaisanterie à
part ! C'est pas une appli c'est le système .... Ouais !
alors là peut-être que Samuel va me faire un cours sur la
notion d'appli, de système, de shell mais ... Est-ce
vraiement clair pour les informaticiens théoriciens
platoniciens eux-mêmes ce que c'est qu'un système, une appli,
un shell. Est-ce que ce ne sont même pas simplement des mots
qu'utilisent des ignorants dans notre genre pour se persuader
eux-mêmes qu'ils y connaissent quelque chose.
Donc cf plus haut, considère qu'emacs fait parti du système
au même titre que bash et tu résouts tes problèmes
philosophiques ...
L'unique question qui vaut ensuite, et je te l'ai déjà dis
mais je le répète, ça n'est pas qu'est-ce que ci ou qu'est-ce
que ça, l'ontologie c'est bon pour les philosophes, la vraie
question c'est : étant donné un ensemble de programmes
systèmes ou appli ou que sais-je est-ce que ça répond oui ou
non a mes besoins ?
> m'en suis fait et fini par l'aimé, donc difficil de m'en
> défaire. Mais
J'ai un atout dans ma manche ! emacs émule vim il me semble
... Ah ça c'est sournois, je te l'accorde ! Mais si la
question est un problème de features et de keybindings
... Retour à la case départ. Quand j'ai commencé à utiliser
emacs, je l'avais complètement rekeybindé pour retrouver les
réflexes de mon ancien éditeur (sprint de borland !!! et oui
ça c'était mort avant que tu naisse !). Par la suite j'ai
pensé qu'il était plus astucieux de gardé les keybindings
d'emacs qui sont en fait si j'y ai compris quelque chose,
ceux de la readline donc ceux du bash aussi !
> 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
Ah mais si tu ne refuses pas de tester, tout est possible ! Y
compris de discuter ensemble et dans la bonne humeur encore
des siècles !
> 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
C'est ma conviction profonde. À l'appui de laquelle j'ai mes
11 ans d'expérience et les tâches réalisées grâce à
emacs. Mais je ne t'interdis absoluement pas d'essayer de me
faire douter ! J'ai un pot un peu anar qui m'a dit un jour
"le doute est l'hygiène de l'âme" ! !
> 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.
Hum bon ! La question est aussi après celle d'un
environnement de programmation unifié comme l'offre
emacs. Isolément chaque manip est sans doute réalisable
autrement mais dans emacs on pourra développer voire utiliser
des librairies adaptées à un grand nombre de
situations. C'est vague, mais tu vois sans doute l'idée.
> 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é.
Oui et en terme de rationnalité de programmation ça ne me
semble pas non plus très satisfaisant. Mais bon ça met en
lumière des features de w3m et de vim et ce n'est jamais
mauvais d'avoir appris quelque chose.
> C'est pourquoi il faut un programme inter-console pour répondre à ce
> besoin de presse-papier.
Ouais là je doute toujours. Un seul emacs dans une seul
console fait le même boulot alors ... Si même tu y tiens
vraiement tu dois pouvoir ouvrir ton vim comme sous process
d'emacs. C'est ultra pervers mais bon pourquoi pas finalement
!
>
>> 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
Sam une question : s'agit-il d'apprentissage du système ou
d'utilisation du système ? Moi quand je suis arrivé sous
linux, j'avais tapé des années sous dos et même sur des
machines mécaniques ! Alors le coup de taper 10 lettres
sans me planter je savais faire. Je reconnais que
quelqu'un qui aborde une machine pour la première fois
sera en effet rassuré s'il a un feed-back de sa frappe
clavier au moment du login. Cela dit, le sens de mon
propos n'était pas que tu n'a pas besoin de feed-back
sonore à ce moment-là, mais qu'un feed-back rudimentaire
(echo caractère par ex) est amplement suffisant. Tu n'as
pas besoin à ce stade des capacités d'intégration
d'emacs. Donc tu peu suppléer avec speakup ou brltty.
> 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
Et je rigole mais quand les voyants tapent leur mot de passe
ils en sont au même point puisque le password ne s'affiche
pas ! Et j'en connais des voyants qui réitèrent 20 fois
l'opération avant d'arriver à se loguer ! Surtout qu'en
général tu dois choisir un password qui soit autre chose que
le prénom de ta copine !
> 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é !
Et ben moi aussi !
>
> A bientôt:
Et ça j'espère bien ça me donnera l'occasion de boire un coup !
Pierre
> 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
>
---
--
CarrefourBLinuX MailingListe
Pour obtenir de l'aide, envoyez le sujet help à:
carrefourblinux-request@xxxxxxxxxxxxxxxxxxx
Archives:
http://listengine.tuxfamily.org/lists.tuxfamily.org/carrefourblinux