Re: Meeting Minutes Published - November 11, 2010
- From: Eitan Isaacson <eitan monotonous org>
- To: Cesar Mauri <cesar crea-si com>
- Cc: foundation-list gnome org, gnome-accessibility-list gnome org
- Subject: Re: Meeting Minutes Published - November 11, 2010
- Date: Fri, 17 Dec 2010 14:29:29 -0800
I agree with Cesar.
In Orca's upcoming refactor a certain level of abstraction should be provided to allow porting to different platforms.
Maybe in some kind of future NVDA and Orca could actually share a codebase or at least some modules. But this is just wishful thinking for now.
This is how LSR was designed, it was abstracted (even to a fault), and kept a future Windows (or Mac) port feasible.
Users win from a multi-platform screenreader because:
1. No learning curve when switching platforms. Today, besides learning a new platform, users need to learn different screen readers with very different interaction modes, NVDA or JAWS on Windows, VoiceOver on Mac, and Orca on Linux. It would be cool if a blind user did not have to worry about that. This would make the screen reader users competitive when it comes to technology proficiency since they are not locked down to the one AT they are used to on one platform.
2. It would do what Firefox did to the web to accessible computing. Desktop Linux is marketable today not because it reached feature parity with commercial offerings, but because it offers exactly the same web experience with Firefox or Chrome. The Free Desktop would be more attractive to blind users who are already familiar with it's great screen reader from the windows world. The screen reader and browser would be identical, and the experience would be too.
Again, just wishful thinking :)
On Fri, Dec 17, 2010 at 1:57 PM, Cesar Mauri <cesar crea-si com>
El 17/12/2010 12:21, Piñeiro escribió:
Thanks for your explanation which helped me to understand better how Orca works.
So now the problems. Take into account that turn Orca cross-platform
is not just be able to compile Orca on Windows. There are more pieces
that it would be required to "turn":
* at-spi: Orca is a screen reader that gets all the information from
at-spi. So at-spi should also be migrated.
* new bridge: right now, the communication path between the apps and
at-spi is the ATK bridge or the QT bridge. Windows apps doesn't
use ATK, AFAIK, it uses IAccessible2. So a new bridge should be
So, turn cross-platform Orca means turns two modules, and create a new
one. This is a really big amount of work to do. And we enter in a
vicious circle. You proposed that turn in order to get funds. But we
would require a really big amount of funds to get that.
Agreed. Given this scenario it seems clear that the effort is greater than the return.
However, IMHO, I think that this approach could be taken into account for some new
AT projects, especially those less dependant on specific api's (for instance, I'm thinking
of AAC software). Beyond probably increasing funding opportunities (according to previous
comments in this thread), a larger user base could be reached. Is just my opinion.
] [Thread Prev