Re: Dynamically loading AT and ATK+ [was Re: Comments on GTK+ patches from Atk tarball]
- From: Pavel Machek <pavel ucw cz>
- To: Bill Haneman <bill haneman ireland sun com>
- Cc: Owen Taylor <otaylor redhat com>, gtk-devel-list gnome org, Bill Haneman <Bill Haneman sun com>
- Subject: Re: Dynamically loading AT and ATK+ [was Re: Comments on GTK+ patches from Atk tarball]
- Date: Mon, 2 Apr 2001 23:34:25 +0000
Hi!
> The requirement is for accessibility support to be dynamically
> loadable on a running application; for instance I am running a program
> and have a problem, I call my co-worker Ed to offer an opinion. If Ed
> is blind, he will need a screenreader in order to see what my app is
> doing, but of course I have been running the app without a
> screenreader.
>
> A screenreader can be cranked up and connect with a running "SPI", no
> problem. But unless I have been running my app with the runtime
> accessibility library loaded, any programmatic accessibility
> properties that the app may have provided will have just gone into the
> bit bucket, and I will only have the "default" accessibility
> properties if I dynamically load the accessibility module. Of course
> one answer is that if I am in an office where AT may ever be needed, I
> always load the runtime library... but how friendly is that? It would
Not too friendly, but I believe it is the right approach. It seems much
easier without this feature.
> 1) Start app without libagtk
> 2) App sets an accessibility property, such as an icon label.
> Skeletal implementation of ATK in libatk stores this property, but
> does not load libagtk or compute any other ATK properties.
-> memory overhead even for users not needing accessibility.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]