| Re: Environnement(s) sonore(s) Was: Re: [CBLX] Du nouveau sur Speakup ? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/carrefourblinux Archives
]
Salut Pierre, super cette conversation,
où j'apprends de plus en plus sur emacs.
En effet, si emacs permet de gérer les applications en sous-process,
tout en simulant leurs raccourcis clavier et récupérer leurs sorties d'écran,
il faut aller voir ça de plus près.
En ce moment je lis et teste pas mal de code source de librairie permettant de
controler le clavier et l'écran sous linux.
C'est d'abord pour bien comprendre cette philosophie qui m'est tout à fait nouvelle,
mais aussi et surtout parce que je suis arrivé à la conclusion,
après beaucoup de nuits de tests,
que sous linux en console, il faut développer une librairie d'interface
utilisateur (UI) partant de zéro, (from scratch) pour assurer l'accessibilité des applications utilisant cette librairie.
En gros, je compte refaire une librairie ncurses mais exclusivement pour le déficient visuel,
donc, avec les besoins du dv, sans les besoins visuels du voyant
comme le graphisme, et les couleurs.
De plus, seule une dizaine de composant est nécessaire :
boite à liste, boutton, case à cocher, champ d'édition, ...
mais pas de treeview, de grille, de progressbar, palette de couleur ... ce qui devrait
raccourcir considérablement le temps de développement.
Néanmoins, les quelques composants auront un gestionnaire d'évènement
très avancé propre au dv comme :
un callback (évènement) lorsque le curseur arrive sur un composant,
un callback à la sortie du composant, un pour la sélection d'un élément du composant,
keypress, keyup, keydown etc ...
Si je commence à penser ainsi, c'est qu'après avoir tester toutes ces librairies
fait pour le voyant, il manque souvent plusieurs de ces évènements important
pour le non visuel.
Un exemple qui me frappe, est qu'aucune
propose gestion des tabulations, c'est-à-dire l'ordre
dans lequel on passe d'un objet à un autre en pressant la touche Tab.
Pour le visuel, ce n'est pas important, puisqu'il a une vue globale de l'écran.
Par contre pour le non-visuel, cela permet de hiérarchiser les informations,
pour éviter de faire le tour de l'écran.
A ma grande surprise, la librairie Newt est très accessible,
mais comme ça n'a pas été fait pour développer de grandes applications,
(ça a été fait dans le but de créer des installateurs interactifs de logiciels
ou de système), il lui manque donc pas mal de gestionnaire d'évènement.
Mais je dois dire qu'il est parfait pour de petites applications,
et très simple à programmer.
Je pense que c'est ce que je vais utiliser pour mes besoins, en attendant des jours meilleurs.
Tout ça pour dire qu'une fois bien avancé dans cet apprentissage from scratch,
ce qui va me prendre au moins deux mois, avant de trouver vraiment
(ou plutôt de créer) ce que je cherche,
après ça, je me pencherai sur emacs et sa philosophie, et je testerai
les interfaces festival.el et ecasound.el, pour avoir une
bonne vision de la situation.
Voilà comment passer de très bonns vacances !
Franchement je ne comprends pas ces gens qui vont à la plage ou en balade alors
qu'il y a tant de code source à lire ?
> 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.
Sur le fond on est d'accord, mais sur la forme je préfère
Lecteur d'écran, un terme qui veut tout et rien dire plutôt que
"intégrateur de tâche sonore", certes plus précis, mais moins vendable.
De toute façon je n'entends pas la même chose selon le terme :
Pour moi, un environment sonore est un système qui va chercher
les autres applications, et leur demander de quoi il en retourne, de quoi
s'agit-il, peut-on faire quelque chose pour les soulager ?
Tandis qu'un lecteur d'écran attend là, tapis dans un coin (tâche de fond),
toute application qui passe, et récupère le maximum d'infos pour
l'utilisateur.
La démarche n'est pas la même car d'un côté
il faut un apprentissage pour chaque appli, en gros une feuille de route
qui est à chaque fois différente,
et de l'autre côté, un apprentissage global et ensuite faire au cas par cas.
Mais si l'on peut arriver au même résultat, avec des méthodes
différentes, que demande le peuple ?
Pour ne pas rallonger ce mail, je continuerai dans un autre message.
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