Ok, I agree, that it is ridiculous that currently accessibility has to be activated manually. Still we have the problem that our current accessibility technology just sucks too much for being enabled by default. So obviously we need a plan to fix the situation. IMHO the suggested plan of just enabling accessibility by default in its current state DOES NOT WORK, because (see above) our technology sucks: It is slow, wastes resources, is crashy. What makes me wonder: Can't we improve our to enable those features on demand? As far as I understand the accessibility tool chain it consists of those components: - ATK, which provides GObject interfaces describing widgets from an accessibility point of view - libgail*, a set of loadable GTK+ modules, which attaches the ATK interfaces to widgets - AT-SPI, some daemon which collects/propagates accessibility information received from other processes via some RPC - libatk-bridge, a loadable GTK+ module which maps ATK to the RPC mechanism used by AT-SPI First one minor technical problem: With the progress of banning Orbit/Bonobo from GNOME, the AT-SPI daemon becomes more and more alien. It is about time to port that part to D-BUS. AFAIK there is code already. Now about our real problem: Loading this features on demand. - ATK: always there since GTK+ links to it - AT-SPI: trival to launch on demand: Bonobo activation and D-BUS activation provide the tools. - libgail*, libatk-bridge: They are just loadable modules, aka. plugins, so there is absolutely no fundamental problem in loading them on demand. Currently we just cannot load them on demand, because on demand loading has not been implemented yet for GTK+ modules: Currently you have to list your GTK+ modules in some environment variable, which obviously cannot be modified after launching a program. Still GTK+ has the ability to monitor XSETTINGS for instance, so it should be trivial to load modules when some XSETTINGS property changed and indicates the need to load some module. This gail and atk-bridge just have to be aware of getting loaded lately, so that they can enumerate the already existing widgets, attach ATK interfaces and register them with AT-SPI. Ciao, Mathias Am Donnerstag, den 31.07.2008, 00:31 +0000 schrieb Dylan McCall: > > Hi All: > > > > I recently had a nice discussion with the release team about the > > viability of enabling accessibility (i.e., the AT-SPI infrastructure) by > > default for GNOME. As a result of that discussion, I'm approaching the > > broader GNOME community with a proposal to do this. :-) > > > > Accessibility has currently enabled by default for development builds > > since 2.17 (http://bugzilla.gnome.org/show_bug.cgi?id=362457), so there > > has hopefully been a fair amount of testing-in-the-large with it > > already. We also recently got rid of one of the last obviously nasty > > things it was doing -- gnome-session no longer pops up that annoying > > "the at-spi infrastructure didn't start" window. > > Even in the event that this proposal does not happen, I think GNOME's > arrangement for enabling accessibility lacks courtesy at the moment. For > example, try (without a11y turned on) to open Mouse Preferences and > enable one of the mouse accessiblity features. Boom! Horrible error > message: > > "Mousetweaks requires Assistive Technologies." > > I used this as the first example in a little post I made regarding > courteous software. > > Let's pretend for a moment I am a disabled person who has trouble with > mouse buttons. I am trying to turn on a critical accessibility feature, > and I think I see light at the end of the tunnel. > ... > Nope, never mind. Instead, this program decides to tease me! It throws a > cryptic error message, telling me that it requires "assistive > technologies". It essentially orders me to give it these technologies, > and it refuses to do anything until I satisfy its demands. I can feel > the confused phone calls starting already! > In the layman's thoughts: Of course it "needs assistive technologies"; > it /is/ an assistive technology! This error message is lazy, cruel and > unusual. It does not offer to enable assistive technologies, and it does > not elaborate on what the heck it means to begin with. It simply refuses > to work, leaving people to give up or phone their relatives. There is no > reason for this evil, either; the software here has complete access to > the necessary controls such that it should be able to transparently > enable "Assistive Technologies" without the end user needing to think > about it. At the least, it could have a button leading to the "Assistive > Technologies" preferences or a kind explanation of what "assistive > tecnologies" are if not the technology the user is trying to enable. > > Of course, GNOME normally does better than this. This project is > characterized for never having unnecessary popups, always presenting the > user with answers instead of pounding him with problems. Polishing loose > ends like that one could solve a lot of accessibility problems > magically. > > As for enabling accessibility by default, my personal thought is that > distribution installers should offer that option in there, perhaps just > "install in accessibility mode" at the boot menu for the live CD > ones. If someone desperately needs assistive technologies, he is still > going to have trouble enabling the components all himself after already > struggling through an installer. The distributors should have mercy > early on. Perhaps there is something GNOME can do to encourage such > practise. > Come to think of it... if you'll excuse the ignorance here, can't we > just have another session choice alongside the regular GNOME one in GDM > for Accessible GNOME, or is there something extra extra magical > happening? > > Whichever way, the user should not have to think "enable Assistive > Technologies" before doing anything, and I too would love to see a > movement towards that. I have always thought it central to GNOME to > avoid hounding the user with unnecessary choices. Therefore, he should > find the particular assistive technology he wants and enable that > without needing to think about the underlying systems. I don't think > logging out and logging in is a big issue, particularly when first > setting up. Besides, doesn't session saving work here? ...Maybe, with > that in mind, there could be a magic "refresh this session" button that > saves the session, logs out and logs back in really quickly, but that is > way off topic. > > > > Bye, > -Dylan McCall > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Mathias Hasselmann <mathias hasselmann gmx de> Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil