Environnement(s) sonore(s) Was: Re: [CBLX] Du nouveau sur Speakup ?

[Pierre Lorenzon <devel@xxxxxxxxxxxxxxxxxxxx>]

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