[Accessibility] Common Configuration Framework

[Tomas Cerha]

Dear list members,

As a discussion concerning this topic was raised at several independent
occasions lately, I believe it is a good time to start coordinating our
efforts.  It seems that there is a broader need for a common framework
with the following key features:

 * provide a graphical user interface as well as an alternative
   user interface to modify configuration settings of various assistive
   technologies

 * manipulate the configuration of different existing assistive
   technologies written in different  programming languages running
   on different platforms

Let me summarize the relevant discussions first.  AFAIK, the need for
some sort of a configuration tool was indicated by the following projects:

  * Orca
  * Ubuntu Accessibility
  * Speech Dispatcher

About two months ago, a discussion about Orca configuration GUI was lead
between Sun and Brailcom.  The solution proposed by Brailcom has several
important features, which make it viable in the general context:

  * The GUI is generated automatically (based on the definition of
    available configuration options) by a separate frontend module.
    Although PyGTK was desired for Orca, alternative frontend modules
    can be implemented easily for QT, HTML, console or any other kind
    of UI.

  * The backend for storing configuration values is also isolated in a
    separate module, so alternative storage mechanisms can be used in
    addition to the GConf backend.

The proposal was designed for the Python environment.  It needs to be
extended to deal with applications written in other languages running on
different platforms, but I believe the key concept can be used as a
starting point for the Common Configuration Framework.  You will find
the full text of the proposal attached.

Independently from this, Henrik Nilsen Omma proposed an interesting
solution in his post "Common AT config panel" to Ubuntu, Gnome and KDE
accessibility lists.  In short, he suggests a common user interface to
configure all assistive technologies from one place.  The fact, that
each technology uses a different configuration mechanism (including
gconf, dotconf, raw Python file, etc.) should be hidden by creating an
intermediate layer.  Please read the whole thread at
http://mail.gnome.org/archives/gnome-accessibility-list/2006-April/msg00079.html
for complete information.

Brian Cameron pointed out a related Freedesktop activity at:
http://freedesktop.org/wiki/Standards_2fconfig_2dspec.  I don't know
what is the status of the work there, but definitely, I will contact the
authors.

Also several other posts scattered around various accessibility related
mailing-lists point out, that on one hand, we need to provide a
consistent and accessible GUI for configuring the assistive technologies
and on the other hand, we must not rely just on the GUI, since the GUI
may not be accessible, when the assistive technologies are not
configured properly.

If there is a broader interest for such a Common Configuration
Framework, I can try to write a new proposal which merges all the ideas
from the above mentioned sources and hopefully also any new ideas coming
from further discussion.  I can currently express an interest to use
such a framework for the Speech Dispatcher project.  I'd be grateful if
people from other accessibility related projects can express their
willingness or unwillingness to join this effort either actively
(contributing the development of the framework) or passively (making use
of the framework when it exists).

Let me emphasize, that all the known use cases currently have a very
basic configuration support.  It is very important to say, that the
intention is not to rewrite a lot of code and redesign a lot of current
software.  The problem is, that a very similar code should be written
for many projects and we see a way to avoid duplication with an
immediate advantage for the user -- a consistent and flexible
configuration interface to "everything".  The intention is to have
concrete results in a short time implementing the most needed parts
first, but designing them to allow all the mentioned flexibility.

Best Regards,

Tomas Cerha

-- 
Brailcom, o.p.s. http://www.brailcom.org
Free(b)soft project http://www.freebsoft.org
_______________________________________________
vyvoj mailing list
vyvoj at lists.freebsoft.org
http://lists.freebsoft.org/mailman/listinfo/vyvoj
-------------- next part --------------
Orca Configuration GUI Implementation Proposal
==============================================

Aims
----

The main focus of the proposed solution is to minimize the effort required from
an Orca developer when using the configuration mechanism.  Since changes into
the set of supported configuration options are unavoidably a frequent task
throughout the development process, necessary modifications of the graphical
user interface can be one of the major sources of wasted resources.  Our
objective is to avoid this problem.

The intention is to generate the GUI automatically based on an independent
specification of the configuration options.  Changes in this specification will
automatically change the GUI, without redesigning the dialog each time.  New
options can be added, options can be easily grouped and rearranged without
any GUI programming.

Another advantage of automatic GUI generation is the consistency of the
generated user interface and a chance to influence the presentation and
accessibility of the GUI at one place.


Overview
--------

The whole problem decomposes into the following (more or less independent)
fields:

  * Definition of an API for specification of available configuration options
    and their properties.

  * Implementation of a configuration infrastructure and an API for its
    integration within the existing Orca code.

  * Implementation of a backend for storing the user changes in configuration
    values.

  * Implementation of a frontend for interactive modification of the settings
    (the actual GUI).

  * Definition of the available configuration options for Orca according to
    the provided specification API.

  * Integration of the whole configuration infrastructure into Orca code
    (retrieving values, reacting to changes, ...).



Definition of Available Options
-------------------------------

All Orca setting will be defined at one place, using a provided API.  For each
setting we need to define the following properties:

  * name: Identifier used to refer to the option within the code.
  * title: Option title displayed in the GUI.
  * description: Textual description of the option displayed in the GUI.
  * type: One of predefined data types, such as boolean, string, number,
    mapping (to be specified more precisely).  Also further restrictions on
    values can be imposed (range, enumeration).
  * default value: A value used when no other source of initialization values
    defines a value for this option.
  * command line availability: A boolean value indicating, whether the option
    is available as a command line switch.  False by default.  (details below).
  * environment variable: The name of the corresponding environment variable.
    If not None, given environment variable will be used to provide an initial
    value (details below).
  * availability: A function returning a boolean value indicating whether the
    option is available in current context (depending on values of other
    options or an external condition).
  * visibility: A boolean flag, indicating, whether the value is present in
    the configuration GUI or not.  This will allow us to manage also other
    settings using the same infrastructure (for example many of the constants
    scattered around the Orca code).

It will be possible to group the option definitions into several named groups.
These groups will then appear in the configuration GUI as separate tabs.  See
the section "Configuration GUI" below for more details about the interpretation
of option definitions within the GUI.

All the power of Python will be utilized to make the option definitions brief,
well arranged and easily maintainable.  Most of the properties will have
sensible default values and many others will be implicitly defined by
sub-classing the specification class.


Initialization of Option Values
-------------------------------

All options and their values will be initialized at Orca startup.  The
following sources of initialization values will be available:

  * Command line options
  * Environment variables
  * Read/write persistent storage (details below)
  * Configuration file
  * Default value

Not all the methods make sense for each particular setting.  The process of
initialization is driven by the option definition as follows (first match quits
the process):

 1. If the option allows a command line switch in its definition and a command
    line switch of that name was passed to the program, the option value is
    used.

 2. If the option defines an environment variable and an environment variable
    of that name is defined, its value is used.

 3. If the user setting of given option was previously saved in the persistent
    storage, this value is used.

 4. If a configuration file exists and this file defines the option, its value
    is used.

 5. When none of the previous sources defined the value the default value from
    option definition is used.

Note, that only steps 3-5 are relevant for most options, but for certain
options steps 1 and 2 allow the user to override the stored value for a session
or an administrator to force an option value when necessary.


Backend for Persistent Storage
------------------------------

The user changes in the settings will be stored to allow their persistence over
multiple sessions.

The storage mechanism will be implemented using the GConf backend.  The design
will allow alternative implementation using a different backend.


Configuration GUI
-----------------

The GUI will be generated automatically according to the definition of options
and option groups.  Each group will be represented as a separate tab.  The
options will appear on the tab in the order in which they are defined.

The presentation of each individual option within the GUI will be consistently
deduced from its definition.  The type of a control will be given by the type
of the option value, as well as validation of user input and conversion into an
internal representation (i.e. string value from a control into an integer).

Any changes in option definitions will be automatically reflected in the GUI

The GUI will be implemented using the PyGTK GUI toolkit.


Assigning Keyboard Shortcuts to Orca Functions
----------------------------------------------

An API will be provided to allow registration of user visible functions from
within the Orca code.  The following properties will be defined for each user
function:
  
  * name: a string identifier used to refer to the function
  * title: user visible title of the function
  * description: user documentation of the function
  * handler: Python callable object implementing the actual functionality
  * default shortcut: the default keyboard shortcut for this function

A function defined (and registered) within Orca code will automatically become
available for keyboard shortcut assignment in the configuration GUI.


Integration Into Orca Code
--------------------------

The configuration infrastructure will provide the following functionality for
Orca programmers:

  * retrieve a value of an option by name
  * register a callback on change of a particular value
  * set the value programatically.

In the first stage a backwards compatible interface will be provided to allow
easy transition to the new configuration infrastructure.  In that stage only
the present Orca functionality, i.e. retrieving configuration option values,
will be supported.  New important features (such as option value change
callbacks) will be added to Orca in the second stage.

In the second stage of integration all changes of option values must be handled
properly.  For many options this may not be a problem, since their values are
re-read whenever they are needed, but other options may require special
handling.  Since the Orca code written in the past did not necessarily take
option value changes into account, it must be checked for proper configuration
handling.


Summary
-------

The proposed solution tries to minimize the effort required from an Orca
developer to include user configurable features within the Orca code.

>From the point of view of Orca developer, there are the following points of
interfacing the new configuration infrastructure.

  * Define an option and its properties.
  * Use the option within the code (get/set its value).
  * Handle the changes of the option value if necessary.

Everything else is managed automatically by the configuration module, including
GUI generation, initialization of option values from various sources, invoking
callbacks on changes, checking the assigned option values (from whichever
source) for validity, proper type-dependent transformations of option values
when they are read and stored, etc.

The solution seamlessly combines the settings coming from configuration files,
command-line switches, environment variables and the GUI.

Additionally keyboard shortcut assignment to Orca "user functions" is solved as
one of the configuration options.  All registered user functions become
automatically available for keyboard shortcut assignment transparently allowing
any of the supported configuration methods (including the GUI).