[Kde-accessibility] Common AT config panel

[Brian Cameron]

Henrik:

I do not think that this completely solve the "how do I set
my accessibility preferences when I can't do anything until the
preferences are set up."

Perhaps a set of hotkeys are necessary to launch the different
accessibility tools so that a user always knows that they can hit
some magic key combination and GOK will start up in a basic dwell
mode.  Perhaps not the fastest GOK settings to use, but enough to
allow the user to navigate through the rest of configuration.

It would be nice if these hotkeys could be defined to be as
consistent as possible across distros.

> There are several new AT apps coming on line that need settings panels. 

Please consider dasher.  It is a great alternative keyboard that
some users with accessibility needs find useful.

>  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.

Perhaps a wrapper API could be written that will hide the details
of whether the KDE, gconf, or python interfaces are being used in the
background.  Perhaps this specification needs to be fleshed out and
become that wrapper API?

    http://freedesktop.org/wiki/Standards_2fconfig_2dspec

> 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.

Some aspects of the desktop are good to be consistent across desktops.
Configuration management seems to be an obvious choice.  I think doing
a GUI via HTML that could be shared across KDE and GNOME would help to
give end users a more consistent and less confusing configuration
experience.  Considering how many users dislike or are incapable of 
configuring things to work.

I think this is a great idea.

> See mock-up: http://people.ubuntu.com/~henrik/at-conf/main.html
> Tarball: http://people.ubuntu.com/~henrik/at-conf/at-conf.tar.gz
> Screenshots: http://people.ubuntu.com/~henrik/at-conf/at-conf-firefox.png
> http://people.ubuntu.com/~henrik/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
> 
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list at gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list