Re: Common AT config panel

[Henrik Nilsen Omma <henrik ubuntu com>]

Hynek Hanke wrote:
> Henrik píše v Ne 23. 04. 2006 v 17:36 +0100:
>   
> > There are several new AT apps coming on line that need settings panels. 
> >  From the user's perspective it would be preferable to have a single 
> > interface for all the AT on the free desktop. The challenge of course is 
> > that we are dealing with apps written in a variety of languages running 
> > on different platforms using different config systems including dotconf, 
> > gconf and a raw python file.
> >     
>
> Hello Henrik and all,
>
> I'd like to propose to move this thread to
> 	accessibility freedesktop org
> so that it is not spread across several mailing list,
> people know where to post replies and we have an archive.
>   
OK, so this message goes to accessibility freedesktop org (I'm CCing the 
other lists, so people know where to continue, but we can drop those CCs 
going forward).


> If this suggestion is accepted, it would be great if the
> original email was resent to Freedesktop and information
> about it is sent to the mailing lists that are currently
> in CC.
>   

The original email is pasted here:

There are several new AT apps coming on line that need settings panels. 
From the user's perspective it would be preferable to have a single 
interface for all the AT on the free desktop. The challenge of course is 
that we are dealing with apps written in a variety of languages running 
on different platforms using different config systems including dotconf, 
gconf and a raw python file.

To start us off I've made a simple HTML mock-up of a common AT 
configuration panel. The layout is loosely based on the new KDE control 
center, where each category of settings is accessed via an icon. 
Clicking on an icon presents the relevant settings, which can be 
organised with further tabs. It's just a shell ATM simply intended to 
convey the idea of how everything can be gathered together. It's just 
raw HTML/CSS so it doesn't actually do anything. The next step would be 
to write a python version that would generate the GUI in real time, 
which then in turn could be linked to a back-end that would read, parse 
and write the config files.

See mock-up: http://people.ubuntu.com/~henrik/at-conf/main.html <http://people.ubuntu.com/%7Ehenrik/at-conf/main.html>
Tarball: http://people.ubuntu.com/~henrik/at-conf/at-conf.tar.gz <http://people.ubuntu.com/%7Ehenrik/at-conf/at-conf.tar.gz>
Screenshots: http://people.ubuntu.com/~henrik/at-conf/at-conf-firefox.png <http://people.ubuntu.com/%7Ehenrik/at-conf/at-conf-firefox.png>
http://people.ubuntu.com/~henrik/at-conf/at-conf-lynx.png <http://people.ubuntu.com/%7Ehenrik/at-conf/at-conf-lynx.png>

The HTML implementation has the advantage of being accessible on both 
KDE and Gnome via any browser and even at the command line via lynx. If 
the layout is designed with the right combination of HTML and CSS it can 
be made to look visually rich and support several viewing modes, yet 
still look completely clean in a text-based browser. It is also quite 
easy to do layout and prototyping in HTML (IMO) so developers from KDE, 
gnome and other projects can help shape the basic framework.

I don't claim that an HTML app can look as polished as a native app and 
obviously not integrate as well. Fortunately, a language like python can 
drive both Qt and GTK front-ends as well. To make this work one would 
need to keep the back-end framework separate from the GUI so that GTK, 
Qt and HTML front ends could each be written easily. (my point of 
reference for this is the espresso installer on Ubuntu which was written 
in this way and got a GTK front end first soon followed by a Qt one). It 
may even be that some projects decide to write the GTK or the Qt version 
before doing a browser-based one. That would be fine too, as long as the 
broader landscape is kept in mind so that porting and integration can be 
accommodated later.

So, is this realistic? Can we construct the Orca interface so that a) 
the GUI and back-end are kept separate and b) so that it can run either 
as a separate program or as an integrated part of a common config panel? 
If so, we should be able to build a Speech Dispatcher interface using 
the same principles, followed by KTTS and other ATs. The big winner will 
be the end-user who will be able to access all these settings in one 
tidy place, from Gnome, KDE, the command line or across a network.

I know that we have a range of other challenges such as how KDE apps are 
eventually meant to communicate with AT-SPI and just the fact that the 
different apps store the configuration in different formats. But I'm 
trying to simply look at this from the users perspective, who doesn't 
know about those technical details. It would seem that having a unified 
config utility would be a great help for the user. It's also technically 
speaking fairly low hanging fruit for us now because we are creating 
many of these config interfaces from scratch anyway. I also think that 
having a common gathering point at the front-end can help encourage more 
collaboration in the future among AT developers and will make AT more 
visible to the wider FOSS community.

- Henrik


------


Some replies from the ubuntu list are here: 
https://lists.ubuntu.com/archives/ubuntu-accessibility/2006-April/000323.html