GNOME.org
 

Re: [orca-list] some programmers want to contribute to orca.

Hi Yokoy and All:

Just a little history...

As the project lead for Orca, I made the design choice to make it
AT-SPI-centric.  The main reason was that I've seen enough
redesign-the-infrastructure-but-end-up-with-the-same-design attempts in
the years I've been working in this space.  For each redesign, I've seen
talks full of promise and not-quite-there-yet demoware.  I was guilty
for a few of those redesigns as well as one of the first designs in this
space: http://blogs.sun.com/wwalker/entry/rap_rap_rap.

When I had the opportunity to lead Orca, I decided I'd had enough with
infrastructure onanism.  We had been spending years assuming a service
oriented architecture for accessibility was the right way to go, but we
hadn't really proved it with the creation of a real world screen reader
that people can use to do real work.

The AT-SPI and GNOME offered a great platform for Orca development:
thanks to the leadership and evangelizing by the accessibility
community, the GNOME community had embraced accessibility seriously.
Furthermore, the choice to use a programming language independent
interface (IDL) on a mature RPC mechanism and transport helped eliminate
the need to debug/fix/maintain a big facet of the infrastructure.
Finally, the Gnopernicus work at Baum also helped a lot in hardening the
implementation.

By keeping other things constant and focusing mainly on developing a
free, open source, usable screen reader, we are where we are today with
Orca.  More and more people are saying they can use Orca for real work,
which I thinks help argue that a service oriented approach to
accessibility can work.  The work with Orca also helped uncover a lot of
areas in this space that we really hadn't thought about too well: event
ordering, handling different approaches to graphical presentation (e.g.,
window-icon-menu-pointer interfaces versus web interfaces), restricting
an object's role to a single role, etc.  But, we've been able to work
through those things.

At the same time, I watch the KDE/Trolltech work, listen to the OLPC
requirements/philosophy, and keep an eye on IAccessible2.  I also watch
the cross platform work being done by Mozilla, OpenOffice, and the Java
platform -- these people are solving real world problems for their cross
platform accessibility just as they had to solve real world problems for
their cross platform GUIs.

As with many things, there seems to be a jumble of technical and
political issues with misinformation being the cement holding them
together.  This is not to say that the technical issues are not real,
some of them are.  I've been trying to understand more about what's real
and not real in this space and have had discussions with people who
promote and denigrate various technologies.  These include Jim Gettys at
OLPC and Havoc Pennington of DBUS fame.  My goal has been to get past
"this whole thing is xyzzy" statements and understand what has led
people to make the broad brush conclusions they have made.

I discussed the DBUS vs. CORBA issue with Havoc Pennington and Michael
Meeks while I was at GUADEC.  I believe we reached the conclusion that
an RPC mechanism like CORBA is a better solution than a bus mechanism
like DBUS for the type of interprocess communication needed by the
AT-SPI.  One big source of the anti-AT-SPI sentiment was that Bonobo had
issues with handling things such as discovering GUI applications being
run by more than one user on the same display.  In discussions with Jim
Gettys, I believe one of his main anti-AT-SPI arguments had its roots in
the performance/size of Bonobo.

After GUADEC, I began to look at what it would take to pull Bonobo out
of the AT-SPI loop.  This led to discussions about using DBUS for
activation and discovery while keeping CORBA for the communication once
the activation/discovery has been made.  This also led to discussions
with Nokia regarding the N800 (as Peter alludes to below).  I also
discussed the issue with Bill Haneman, who led the AT-SPI work for
GNOME.

It turns out that the work Ariel Rios did for bug 163132
(http://bugzilla.gnome.org/show_bug.cgi?id=163132) effectively starting
pulling Bonobo out of the loop for the AT-SPI infrastructure.  Instead
of using Bonobo to activate/discover the AT-SPI registry, gnome-session
now activates the AT-SPI registry and the AT-SPI registry posts its
CORBA IOR as a property on the root window.  I prototyped some work
yesterday with Orca and with pyatspi to eliminate using Bonobo
(http://bugzilla.gnome.org/show_bug.cgi?id=467044), and it seems to
work.

I believe the only reason Bonobo is still in the loop is to support
backwards binary compatibility.  Bill believes that it should be simple
enough to #ifdef the Bonobo stuff out of the code, which is something I
might try to pursue for GNOME 2.22.  There are already some outstanding
AT-SPI feature requests in this space: 

http://bugzilla.gnome.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=bonobo&product=at-spi&long_desc_type=substring&long_desc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Finally, in light of all the mental and political thrashing around
accessibility API's, I figured it was time to look at providing some
level of thin veneer over the AT-SPI to shield us from changes to the
the RPC and transport mechanism.  Peter Parente and I began discussing
this in early March:

  http://www.themuso.com/irclogs/lsr/2007/%23lsr.03-08.log

We met at CSUN, hashed out the plan at
http://live.gnome.org/GAP/PythonATSPI, and Peter Parente did the
implementation.  The result is pyatspi, which Python-based AT-SPI
consumers are migrating to: LDTP, Dogtail, Accerciser, Orca, etc.  The
Mozilla Foundation is graciously funding Eitan Isaacson to do the Orca
work: http://bugzilla.gnome.org/show_bug.cgi?id=448848.  

The result of using these unified Python bindings for AT-SPI helps with
a lot of issues: Python-based AT-SPI consumers benefit from bug fixes,
performance improvements, etc., without having to do the work
themselves.  In addition, the design choice to hide the exact
interprocess communication mechanism helps make things less brittle, as
Peter mentions below.  This helps Python-based AT-SPI solutions work
should the communication mechanism change, and also helps provide an
answer to choices where people have decided to implement the service
based model the same, but different (e.g., Trolltech).  I'd really be
interested in seeing Trolltech get their work functioning compatibly
with pyatspi.

Anyhow...

Rather than redesign the infrastructure world yet again to make it look
almost exactly the same, I'd like to see us continue to focus on
developing free open source accessibility solutions.  Should change be
needed, I think the impact on existing and useful assistive technologies
needs to be taken into careful consideration.

Will
(Orca Project Lead)

PS - This doesn't mean I'm close-minded about the idea of a cross
platform solution.  I'd love to see that some day.  Right now, I think
we're in a situation where everyone thinks they have the right solution
and everyone else is wrong.  It's not uncommon, which is why we also
have a plethora of GUI toolkits in the world.

On Thu, 2007-08-16 at 11:04 +0200, orca yokoy de wrote:

Hello Peter,
thanks for that fine explanation. I think it is much clearer now why we need another technologie side by 
side to AT-SPI. 

On the XO we have a special case. Nearly all application, say "Activities", and the desktop environment 
"Sugar" are python (pygtk, gygame) based. Would it be possible to modify ORCA in a comfortable way to 
communicate directly with these activities and sugar?

regards,

yokoy

On Wed, 15 Aug 2007 22:51:00 -0700
Peter Korn <Peter Korn Sun COM> wrote:


Hi Halim, gang,


Hi,
On Mi, Aug 15, 2007 at 10:53:06 +0200, orca yokoy de wrote:
  

no, it is not a joke.
AT-SPI is not used by all access technologies. 
    


Which other access technologies you are talking about?


Halim



AT-SPI, the Assistive Technology Service Provider Interface, specifies 
the information that is provided by accessible applications to assistive 
technologies (and the questions ATs can ask of apps).  Our 
implementation of AT-SPI uses CORBA for interprocess communication (the 
AT lives in one process, the app another, so we need some form of 
interprocess communication).

CORBA is an object based interprocess communication mechanism (the 
Common Object Request Broker Architecture).  The user interface elements 
in an applications are represented by 'Accessible' objects, these 
objects have methods, and CORBA allows an AT to make remote, 
inter-process method calls on these objects (e.g. to ask an accessible 
for its name, its role, etc.). 

In order to handle all of the potential issues that can arise with 
inter-process communication around objects, CORBA is fairly large and 
complex.  It has to handle the case when the remote object goes away, 
when a method call fails, etc. etc. 

Memory constrained environments - like the OLCP and the Nokia N800 - 
don't include CORBA (whereas many desktop systems like Ubuntu and 
Solaris do).  So, if we are to bring assistive technology support to 
things like the OLCP and Nokia N800, we need to address this situation.

One idea is to see whether we can slim down the CORBA implementation for 
OLCP/N800, on the assumption that AT-SPI may not need everything that 
CORBA provides.  Another idea is to move do a different inter-process 
communication mechanism (and the candidate choice here is D-BUS, which 
has roots in DCOP and the KDE desktop). 

The big, not fully answered question, is whether a D-BUS implementation 
of AT-SPI can do everything we need.  Recent news from Trolltech labs 
(the folks behind Qt, the main GUI toolkit for KDE) sounds promising on 
this front, but I believe a little more investigation and testing is 
needed before we can be sure this will work for us. 

On a related note, I have repeatedly heard the suggestion of "moving to 
IAccessible2" for UNIX.  To quote the character Inigo Montoya from the 
movie The Princess Bride, "I do not think that means what you think it 
means."  IAccessible2 is a port of AT-SPI (or more specifically, the UNO 
Accessibility API in OpenOffice.org) to Windows.  More precisely, it is 
a port of those portions of the UNO Accessibility API which weren't 
already in MSAA (Microsoft Active Accessibility, the fairly simplistic 
and primitive accessibility API Microsoft introduced in 1997).  Thus, 
IAccessible2 is not a complete API, but rather is an extension of MSAA.  
Also, like MSAA, IAccessible2 uses the Microsoft interprocess 
communication mechanism 'COM' (Component Object Model).  COM doesn't 
exist on OLPC or N800.  While I believe there are ports of COM to UNIX, 
nobody I know of is suggesting implementing COM on UNIX an alternative 
to CORBA for accessibility purposes. 

Because toolkits like GTK+ and Qt have been ported to Windows, and 
because IAccessible2 is gaining some traction on the Windows platform 
with JAWS and WindowEyes providing support for it in their screen 
readers, exposing accessibility information for GTK+ and Qt applications 
on Windows via IAccessible2 makes a lot of sense.  Since IAccessible2 is 
derived from the UNO Accessibility API, which itself is expressed in 
AT-SPI on UNIX, having cross platform apps be accessible on both UNIX 
and Windows via what is essentially the same API (though different 
inter-process communication implementation) makes a lot of sense.


To the question Halim asked, about what AT supports a D-BUS 
implementation of AT-SPI, I believe Trolltech labs a fork of Dasher that 
uses it.  As the GNOME Dasher makes fairly simple and limited use of 
AT-SPI, this is a natural first AT to test out.  But as it is nowhere as 
heavy a user of AT-SPI as something like Orca, this port doesn't 
definitely answer questions about whether we can do everything we need 
to in a D-BUS based AT-SPI.  I know there are other, KDE AT tools, but I 
don't think any of them make heavy use of the API either.  All of them 
pre-date Trolltech's work in this area, and I haven't seen any mention 
of them being updated.


Another important facet to this whole discussion is the question of 
whether we actually need to fork/port AT to use the D-BUS 
implementation.  The Accerciser project introduced a Python abstraction 
layer to CORBA AT-SPI.  Moving our Python-based AT (like Orca) to this 
abstraction layer would allow us to substitute something else for CORBA 
(e.g. D-BUS), without needing to fork/port/modify Orca at all.  Orca 
could use CORBA-based AT-SPI on those platforms where that approach made 
sense, and something else (e.g. D-BUS) on others, where that was a 
better choice.  CORBA and AT-SPI have a lot going for them.  They are 
tested and proven technologies.  It may make sense to stay on CORBA for 
a while in the desktop world, even as we move to something else in 
memory constrained environments like OLCP and N800.


I hope this helps clear up a lot of the questions and confusion around 
these topics


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
_______________________________________________
Orca-list mailing list
Orca-list gnome org
http://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca for more information on Orca
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]