[orca-list] Evolution issues (was Re: Calling all braille users. I need your opinions.)
- From: Joanmarie Diggs <joanmarie diggs gmail com>
- To: Jacob Schmude <j schmude gmail com>
- Cc: Orca screen reader developers <orca-list gnome org>
- Subject: [orca-list] Evolution issues (was Re: Calling all braille users. I need your opinions.)
- Date: Mon, 10 May 2010 14:55:12 -0400
Hi Jacob.
While doing this, please look for instances where information is
brailled but not spoken as well.
Good point. <smile>
Two examples I can think of off the top
of my head:
1. In Firefox, the location and search bars. When arrowing or
backspacing, this change is reflected in braille but not in speech at
all. Also, sometimes the address and search autocompletes do not get
immediately spoken, however they do get immediately brailled.
This one I'll need to check out. Thanks!
2. When composing a message in Evolution, backspacing over a character
is instantly reflected in braille but again, is not reflected through
speech at all.
Yeah, that would be an Evo bug. [1] I filed it against Evolution in
October 2007. Yes, this bug is nearly three years old. Since that time,
Attila confirmed the problem -- back in April 2008. I pinged the bug in
July 2009. Total responses from the Evolution team: Zero. :-(
The reason we are doing the right thing in braille is because we're
getting the entire line of text from Evolution. (It gives us this much.)
The way Orca presents in speech what has just been deleted is by
reporting the any_data field of the text-changed event. We get this
information from other applications; not sure why Evolution is failing
to give it to us. :-(
While we could try to hack and do all sorts of fancy string comparisons,
it would be a hack -- and one that would likely impact performance. The
Evolution guys should finish/fix their incomplete/broken implementation
of AtkText.
Alejandro, since you'd indicated that "We have GNOME developers in our
company that can address communication between different module
maintainers. It seems like a interesting task for us, because unblocking
it is an insurence towards resolution." This one might be right up your
alley. It would be super if you could get these developers to resolve
this bug, because once that Evolution bug is fixed (i.e. in Evolution),
the bug Jacob mentioned will simply vanish and Orca will start doing the
right thing immediately.
Speaking of Evo bugs, Alejandro if your developers are able to address
these sorts of things, you probably should have the full list. Here's
just the evolution-related items: [2]
If the bug is tagged as [blocked] in the summary, that means it is an
Orca bug and that we cannot fix it until the bug blocking us is fixed.
Note that in many cases, as with the issue above, once the Evolution
blocking bug is fixed, there won't be anything for us to do in Orca to
fix things; they'll just start working correctly.
Thanks in advance for anything you and/or your colleagues can do in this
regard, Alejandro!
Related: Try and make sure that Orca isn't collecting information twice
(once for braille and once for speech) unless it absolutely needs to.
Heh. Yeah, I know.... Definitely on the to-do list. Will addressed some
of that with the implementation of a generatorCache, but there's clearly
areas where we're still doing the work twice.
Note that Orca is far from the only screen reader guilty of
this one.
Thank you for saying so. Still, it's no excuse. We need to fix it.
Thanks and take care.
--joanie
[1] https://bugzilla.gnome.org/show_bug.cgi?id=483458
[2] https://bugzilla.gnome.org/showdependencytree.cgi?id=423346&hide_resolved=1
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]