Re: Common AT config panel



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]