Re: [Kde-accessibility] Common AT config panel

[Henrik <henrik ubuntu com>]

Gary Cramblitt wrote:
> An interesting idea.  Just a couple of quick thoughts.
>
> Once KTTS migrates to using Speech Dispatcher as its backend, I envision a 
> single GUI for configuring it and Speech Dispatcher, since they will be 
> closely related.  I'm thinking therefore, that instead of two icons "KTTS" 
> and "Speech Dispatcher", there should be a single icon "TTS".  OTOH, what if 
> the system has multiple TTS interfaces, say GNOME Speech and KTTS/Speech 
> Dispatcher, or SpeakUP and Speech Dispatcher?
>   
We probably need some advice from the usability people on exactly what 
to call each entry and how to group them. Do you envision having KTTS 
feed all the parameters to SD that it needs so that the user wouldn't 
have to set any SD parameters itself? If so, perhaps Orca will do the 
same for SD or gnome-speech (whichever it will use). That would 
certainly be simpler for the user. If not, if there is to be a separate 
SD section, then it makes sense to write that only once and use it will 
all the screen readers and TTS systems that need SD.

I was also thinking that there could be a basic set of settings and an 
'Advanced' button that would allow more fine-grained controls, even 
direct editing of config files.
> I assume this web interface will itself be fully accessible.
>   
Right, but that really needs to be one of our top priorities anyway. All 
the main browsers, Firefox, Konqueror and Epiphany all need to get 
kicked into shape to play nice with the AT tools :) The browser is such 
a fundamental part of the desktop these days, it must be the single most 
used app.

It's something I want to focus more on after Ubuntu 6.06 is released. 
That will hopefully attract an active user base that can help test these 
cornerstone apps and start reporting bugs on them upstream to raise 
awareness and put the pressure on. I want to set up a structured program 
for doing that in the next few months.

Anyway it works in console-based browsers, which I guess can be assumed 
to be accessible to hardware based syths and braille and to speakup. 
Also, I'm not saying the browser-GUI will be the only front-end, but I 
think it's a good place to start because it can be used on both desktops 
equally well and it is easy to prototype/develop on.
> Are you envisioning that when user clicks one these icons, they go to another 
> web page?  
Yes, sorry I should have made the icons clickable; that was sloppy ;)  
It's fixed now (it was just the text link before). When you click you go 
to pages like this: 
http://people.ubuntu.com/~henrik/at-conf/orca_voices.html that can each 
have a whole range of settings.
> Are all the config GUIs XHTML?  If yes, what web languages are we 
> assuming?  XHTML + JavaScript? 
Not really. I'm thinking plain old HTML so that any browser can use it, 
including the very simple console based ones like lynx and links. The 
content would be dynamically generated by a scripting language like 
python. It sounds complicated, but it really isn't. A good example of 
this is the moin desktop wiki, which runs locally and sends the 
interface to localhost to be displayed in any browser using standard 
HTML. See: http://moinmoin.wikiwikiweb.de/DesktopEdition
>  If yes, there are some security issues with  
> having a web page write to a local disk configuration file.  ATM, Konqueror 
> for instance will not permit that.
>   
So with a scripted back-end you don't have this problem because it's the 
script that writes to disk, not the browser. The desktop wiki mentioned 
above does this and runs in any browser. You only write the back-end 
routines that saves the config files once and then you can add separate 
front ends in Qt, GTK and HTML. The browser only has a fairly passive 
role and only when you use the HTML version. If you run it with a 
toolkit front end then the browser never gets called.

- Henrik