Re: Accessibility module loading
- From: "Padraig O'Briain" <Padraig Obriain sun com>
- To: bill haneman sun com, andersca gnu org, michael ximian com
- Cc: access ximian com, gnome-devel-list gnome org, gnome-accessibility-list gnome org
- Subject: Re: Accessibility module loading
- Date: Fri, 14 Dec 2001 09:21:40 +0000 (GMT)
I do not feel competent to comment on the details of Michael's proposal but ...
I take the view that accessibility support should not be an add-on but the
accessibility support for a widget should be in the same library as the widget.
The situation with libgail is anomalous as when we started on it there was no
expectation of being able to complete the work before GTK+ froze and we wanted
to be able to add accessibility support got GTK+ widgets even after GTK+ froze.
If we took this view the only thing we would lose is the ability to dynamically
change accessibility support.
Padraig
>
>
> * The Current state of affairs
>
> Currently accessibility information is loaded on the basis of
> the user setting a GTK_MODULES environment variable before they
> execute the program. This has the following problems:
>
> - User needs to know which libraries an app uses to whack the
> names of the peer libraries into GTK_MODULES
>
> - A blanket GTK_MODULES setup causes galloping inefficiency -
> lots of libraries being pulled into a Gtk+ app unneccessarily
>
> - Bad bonobo-activation support, components won't pick this up
>
> - Accessibility support is not dynamicaly changeable ( ok so
> this is a demo feature I know :-)
>
>
> * What we can do about it
>
> So; here is how I propose we fix it:
>
> The GnomeProgram (libgnome/gnome-program.c) initialization
> setup allows for module information to be passed in; this is excellent
> since it gives us a set of GnomeModuleRequirements for each
> application.
>
> Thus - if enabled [1] it would be possible to grok each of
> these modules and load any approriate ancilliary accessibility
> libraries as neccessary.
>
> Having determined which modules we wish to load; we would hook
> the 'gnome_accessibility_module_init' entry point, I propose two of
> these:
>
> void gnome_accessibility_module_init (void)
> void gnome_accessibility_module_shutdown (void)
>
> The 'shutdown' method is hooked up to a GConf listener on the
> accessibility key - so that we can disable accessibility in-place.
>
>
> * How does this affect the capabilities ?
>
> + Gnome apps no longer need to rely on GTK_MODULES
> + We can easily locate the correct modules - no redundant libs
> need to be linked
> + Bonobo-activation support is fine - working via the GConf key
> + Accessibility is dynamicaly alterable leading to funky demos.
>
>
> * What API changes are neccessary ?
>
>
> No API changes neccessary; unless the change:
>
> - gpointer expansion1, expansion2;
> + const char *prefix;
> + gpointer expansion1;
>
> counts.
>
>
> * What needs doing ?
>
> + libgnome/gnome-program updates.
> + add new gail / at-bridge entry points.
> + guard gail / at-bridge against double inits
>
>
> * Other approaches and points
>
> - Simply make libgnome depend on at-spi and put link
> vs. the at-bridge always - not attractive due to at-spi
> code / API churn.
>
> - Link accessibility always everywhere - again adding
> rather a lot of code that is not strictly neccessary.
>
> - couldn't this module implemented extremely abstractly
> providing an amazing framework for other similar
> things; - not attractive; more complex, less readable
> and there's no time right now.
>
> - but this will mean Gtk+ only programs suck more for
> accessibility you'll still have to export GTK_MODULES.
> True; use the Gnome platform wherever possible, or re-invent it
> endlessly.
>
> * Notes
>
> [1] - I propose that we have something like:
>
> if (have_non_empty_env_var ("GNOME_ACCESSIBILITY"))
> enable = get_boolean_from_env_var (~);
> else
> enable = gconf_get_key ("some_magic_path");
>
> [2] - To do this really well, we need to ram the 'prefix' of each
> module into the GnomeModuleInfo structure; I propose using the
> 'expansion1' element for this; and preferably renaming this to
> 'prefix' - since this information is generaly useful. This (optional)
> rename constitutes the most minor of API changes.
>
>
> --
> mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]