GNOME.org
 

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

  Hi List and Peter.
Apologies, I meant to send the below email to the list rather than peter directly.
----- Original Message ----- From: "Nick Adamson" <Nick NDAdamson com> 
To: "Peter Korn" <Peter Korn Sun COM>
Sent: Thursday, August 16, 2007 7:59 PM
Subject: Re: [orca-list] some programmers want to contribute to orca.



Hi Peter.

I have found this topic quite interesting.
I've just started developing under Linux having been in the windows world for the last 5 years.
ICE, www.zeroc.com seems a very interesting technology as a multi platform IPC middleware.
Back in the past I have spent some time working on windows screen readers and wonder if any of the ideas behind the way they work are possible in Gnome. For example all of the big 3 windows screen readers, (Hal, Jaws and Win eyes,) provide hooks in to the display drivers for windows. The major benefits to this are that the main application developers only need to think about accessibility if there doing something non-standard. also they all use Document object models, (DOM) interfaces to software and off screen models. to get an overall picture and representation of the screen layout.
I have know idea how Linux or Gnome do the display drivers and the different levels of abstraction between the hardware drivers and end application level.
Just some thoughts and musings of a newbie to Linux and developing under Gnome. 

Cheers.
nick.
----- Original Message ----- From: "Peter Korn" <Peter Korn Sun COM> 
To: "Halim Sahin" <halim sahin t-online de>
Cc: <orca-list gnome org>
Sent: Thursday, August 16, 2007 6:51 AM
Subject: Re: [orca-list] some programmers want to contribute to orca.



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


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.11.13/946 - Release Date: 10/08/2007 15:50
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]