[Accessibility] Shoring up D-Bus Accessibility--Can we talk?

Piñeiro apinheiro at igalia.com
Tue Jul 20 03:19:33 PDT 2010


From: Bill Cox <waywardgeek at gmail.com>

> Wow... lots to comment on in this!
> 
> On Mon, Jul 19, 2010 at 4:06 PM, Janina Sajka <janina at rednote.net> wrote:
>>> > Anyhoo.... Alex seems to have found his way into the position of
>>> > unofficial/de facto GNOME a11y lead, plus he's got a much better handle
>>> > on the big picture than I do.

Joanie is somewhat exaggerated about my "power" both on the a11y
community and the gnome one. Related with gtk patches ...

> Does this mean I can bug Alex for GTK+ a11y enhancements?  If so,
> here's a patch...

... I think that I don't have more "GTK+ push power" that you could have.

> https://bugzilla.gnome.org/show_bug.cgi?id=617629

Anyway, after checking the patch, I don't see any problem on the
patch, although in order to work application developers should require
to set the description. Anyway, I will add some comments on the bug,
as probably it should be reassigned to a different component.

But remember that sometimes things on GTK+ can be slow. Right now they
3125 opened bugs.

Nothing to add about the other points.


>>> > * Performance (Key Events, Re-entrancy) seems to be improved somewhat.
>>> > The last time I talked with Mike Gorse about it, however, there was
>>> > still a performance loss compared to the current AT-SPI. Speaking just
>>> > from the perspective of Orca: We need to make Orca more performant,
>>> > independent of the move to AT-SPI2. Therefore, anything that makes Orca
>>> > even less performant is, in my mind, very high priority. But that might
>>> > not be the view of the full community.
> 
> I often ask on the Vinux list, "What are the current biggest problems
> we should fix?"  Currently, the answers seem to be:
> 
> #1 - Speed of Orca with Firefox
> #2 - Speed of Orca with Thunderbird, as well as some bug fixes
> #3 - Speed of Orca with OpenOffice, as well as a number of bug fixes
> 
> This is why I was looking into DBus speed.  I'm just beginning to work
> on understanding all the various contributors to delay.  If anyone has
> some tips, I'd appreciate it!  By the way, I'm thrilled to finally be
> at the point of worrying about performance.  For a long time, Vinux
> users had even bigger complaints.  As Joanie said, slow is better than
> not working at all.
> 
>>> Reading Mike Gorse mail [1], this seems that he has an idea that
>>> involves use old cspi code. This means that there are a possibility
>>> that this task help the CSPI one (see following CSPI item).
> 
> I haven't read his e-mail, but I doubt that we're seeing significant
> delays because of Python bindings.  Compared to 200 microseconds, how
> much delay can Python add for one method call?  Of course, I'm mostly
> ignorant of the real sources of delay, so I don't really know what I'm
> talking about.
> 
>> I am very keen to have our ATs and underlying messaging performant. I
>> have always been of the opinion that computers should wait on users, and
>> not the other way around. It has troubled me from the start that
>> performance was at risk in our move from CORBA to D-Bus.
> 
> Amen!  It amazes me that a 2 gigahertz computer can have delays in
> reading a web page that my brain can sense, given that neurons operate
> on about a 10KHz bandwidth.
> 
> Anyway, I estimate that on my 2 gigahertz laptop, every DBus method
> call takes 200 microseconds to pass two messages, while simpler IPC
> programs run about 20X that fast.  I read the DBus spec, and other
> than "requirements" to do a lot of checking that I'm tempted not to
> do, the spec itself seems fairly efficient.  One idea might be to have
> a "turbo" mode which when enabled causes messages to bypass the
> existing dbus code and go directly to a simpler, faster interface that
> runs 10X faster.  Another idea might be to propagate the dbus filters
> to the client applications so that each application can determine
> which other applications need a message, so that only direct messages
> are sent, and so that messages without listeners are never sent.
> 
>>> > * Firefox is reportedly fixed. (And were it not, I'd consider that to be
>>> > something the Mozilla guys should be helping look into. But that's
>>> > another topic for another time. <smile>)
>>>
>>> So this means that Firefox doesn't crash using at-spi2 as Mark
>>> reported, but I suppose that there are still work to done
>>> there. Right?
>>>
>> Yes, another topic--but important. Let me just ask bluntly, did Mozilla
>> accept patches upstream? Or are we still relying on Orca
>> workarounds?
>>
>> If the latter, then I think we need to make an issue of
>> this. I understand they've lost people--but we all have. We're
>> adjusting. They need to not lose us as they adjust.
> 
> I've had a working patch to a critical Firefox navigation bug, with a
> working mochitest test uploaded for weeks:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=546068
> 
> Urgency at Mozilla to include critical Linux a11y patches is very low.
>  I think we should have our own patched version of Firefox that we
> test against.  I don't know how Orca regressions can pass with Firefox
> 3.6 without the patch above.
> 
>>> > it needs to be easy for users to get AT-SPI2 as well as to switch
>>> > between it and the current AT-SPI. A pre-requisite to that would be the
>>> > items under Installation and Packaging, namely options must be
>>> > documented and, ideally, packages provided by distros. Thus I'd consider
>>> > Installation and Packaging to be the next priority. To be honest, at
>>> > least in terms of what Orca needs, when the call for testing is put out
>>> > and the ability to perform the testing is made easy, the community comes
>>> > through. Often within minutes. Truly amazes me.... Anyway, the point
>>> > being: While user testing "vital" I wouldn't call it a "priority" in and
>>> > of itself, because it will just happen -- as soon as the packaging and
>>> > documentation are done.
> 
> I also agree.  Vinux users are eager to try out the new at-spi2 system
> and Gnome 3.  There will be plenty of testers when you're ready to say
> "go!"
> 
>>> > current solutions for voice recognition for GNOME will no longer work
>>> > unless they are converted to Python or implement D-Bus directly. I think
>>> > the GNOME a11y team needs to decide what the priority of CSPI is. The
>>> > question has been raised before (in the context of voice recognition),
>>> > but no conclusion has been reached. Perhaps the possibility of funding
>>> > will help elicit a response. <smile>
> 
> People who can't type are currently poorly served by *-nix. There's
> just no good open-source voice recognition engine worth using in a
> large-vocabulary continuous recognition mode.  I'm recommending Simon,
> because it works with small vocabularies and has a powerful command
> creating and sharing facility.  I think we could make programming by
> voice with Simon practical, and we might attract some of the many
> excellent programmers who can't type due to RSI injuries.  These poor
> guys are not well served by companies like Nuance, and there's room
> for real advances.  I believe it should be easier to beat Nuance at
> programming by voice productivity with low quality speech recognition,
> than it will be beating Freedom Scientific.
> 
>>> About voice recognition, both "GNOME Voice Control" and "VEDICS"
>>> (programs to control gnome desktop using voice) are using deprecated
>>> CSPI bindings, so those projects are in fact in a dangerous state.
>>>
>>> Anecdote: When I raised that, VEDICS developers answer was that they
>>> started VEDICS project just some months ago, and they want to finish
>>> it, and then they will have time *to port it to python*. IMHO, this
>>> kind of "once the scope and implementation of a program is defined,
>>> port that to a (totally) different language would be easy" sentences
>>> are just pure (noob) optimism and likely to fail.
> 
> Both projects have terrible recognition problems, and neither are
> currently of any real use, in my opinion.  I think we can live for a
> while without the ability to speak menus, buttons, and links, and that
> we should instead focus on helping people who are able to point a
> mouse.  What they need, IMO, is commands that do stuff similar to what
> Simon and Vocola do.  It should mostly be possible with our poor
> quality recognition engines.  It's enough to do a lot, like writing
> poorly commented C programs, for example.  It would look just like all
> the other Linux code!
> 
>> I'm also keen to solve the root access issue in a generic way. To me
>> it's insufficient that it's solved in one particular distro. Distros can
>> also change their minds and drop things. We need a wider, Linux-wide,
>> solutions that all the distros must package. I acknowledge and applaud
>> Bill's work creating Vinux. But, I think we can't allow the mainstream
>> distros therefor to wash their hands of any responsibility to
>> accessibility support.
> 
> I agree!  The problem seems to be bugs in gksu.  I don't know why gksu
> stopped being a simple GTK+ wrapper around sudo, and instead morphed
> into an independent monster of massive complexity.  Given that we're
> talking about basic security, it's nuts to hav two independent
> systems.  There must have been a motive, but my preferred solution is
> to force gksu back to being what it was intended to be.  We could
> rewrite it with a simple Python script using policy kit, and I know of
> no reason not to do so.  As is, I've got a simple bash shell in Vinux,
> and a task on our list to rewrite it.  Maybe we could track down the
> gksu devs and try to understand why they need all the complexity, and
> maybe have them fix their code?
> 
> As for upstream washing their hands of accessibility support, I think
> that's what Vinux is here to fix.  Luke at Ubuntu is working very
> closely with us now days.  I'd say he's doing more good technical work
> than me, and he's leveraging everything he can for Ubuntu.  I don't
> know how to get other major distros interested, but the guys who are:
> Open Solaris, Debian, Arch, Ubuntu, Knoppix... you know the distros.
> These guys are getting fixes and improvements faster than before, I
> believe in part because of Vinux.  Hopefully the non-a11y friendly
> distros will be shamed into caring a bit more as their competitors
> pull ahead.
> 
>> Adding one more, related point to this list, there are still distros not
>> supporting accessible login (GDM) out of the box. And, I believe we
>> still have issues around the audio environment, especially when we
>> consider that we need users to be able to use console as well as the
>> desktop environments
> 
> It's so nice to hear someone supporting console use!  There seems to
> be a push to eliminate them entirely, but most blind Vinux users seem
> to spend most of their time in the consoles.  In a year or so, I'm
> hoping we can get Gnome/Orca working so well that the blind will give
> up console use, but we've got a ton of work to get there.
> 
> As for audio environment, I assume you mean PulseAudio.  I think blind
> users are still steaming mad over that whole debacle.  Even Ubuntu
> Maverick will have trouble shipping with a usable console screen
> reader, unless someone like Luke catches fire and writes a ton of
> solid user-session code.  Until that happens, the only popular distros
> for the blind are likely to be Solaris, Knoppix, Vinux, old versions
> of popular distros like Ubuntu and Fedora, and seriously hacked up
> machines where users purge pulseaudio altogether.

===
API (apinheiro at igalia.com)


More information about the Accessibility mailing list