[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KOffice screen readers
From:       Gary Cramblitt <garycramblitt () comcast ! net>
Date:       2006-05-17 22:13:34
Message-ID: 200605171813.34291.garycramblitt () comcast ! net
[Download RAW message or body]

Peter, please feel free to join in on this discussion.  You may wish to 
subscribe to the koffice-devel mailing list 
(https://mail.kde.org/mailman/listinfo/koffice-devel), or I can forward 
messages for you.

On Wednesday 17 May 2006 08:01, Sebastian Sauer wrote:
> Hi Gary, hi *
>
> On Sunday 14 May 2006 15:32, Gary Cramblitt wrote:
> > Given the Orca approach Peter mentions, it would appear that providing a
> > rich scripting interface into document content might be a good way for
> > KOffice to go.
>
> If I understand it correct, Orca is written in python. So, the for me
> logical step would be to provide Kross-bindings to KWord and make it that
> way accessible from within python too.
> How would this affect the AT-SPI bridge which afaik are maintained/provided
> by TT? and if we use the AT-SPI, would it make sense to have
> kword=>kross=>e.g. python=>AT-SPI or ....? 
> hum, to make it short; I guess I still miss the point about scripting vs.
> AT-SPI :)

There are two ways I can see the scripting to AT-SPI being implemented:

kword ==> kross ==> python ==> AT-SPI

kword ==> kross ==> python ==> QObjects ==> AT-SPI

In the second approach, the AT-SPI interface occurs through the QAccessible 
interface.  So the script creates QObjects and fills them with the data 
needed for the QAccessible interface.  I'm assuming that Python has some 
means to create and manipulate QObjects?  To the extent the underlying KWord 
data model meets the needs of AT-SPI, scripts could simply expose those 
objects, assuming they are based on QObject.  This approach is "more 
complicated" but it offers some independence from API changes to the AT-SPI, 
which is still undergoing revision.  Since the GUI exposes all the on-screen 
widgets (which are also based on QObjects) via QAccessible, the first 
approach would mean that two different "channels" of communication are 
occurring between KWord and AT-SPI.

It is hard to say what this will all look like in the end, since we don't have 
any real implementations to play with.  For now, all I can say is that Kross 
should expose as much of the document structure detail as it can; we'll work 
out the accessibility logic later.  The Accessible Document links I mentioned 
previously give you some idea of what kind of information about the document 
is needed.  Sections, paragraphs, lists, fonts, frames, figures, etc.

> if we don't use AT-SPI, how
> would that limit us if we like to offer support for other screenreaders
> too?

Basically, what I'm saying is that KOffice should not interface directly with 
AT-SPI.  Rather, QAccessible is *the KDE* accessibility interface.  The 
infrastructure behind that (probably AT-SPI, at least on Linux and Solaris 
machines) is up to others.  Let's say someone wanted to use the Java 
Accessibility API instead of AT-SPI.  With the second approach, they would 
build a bridge from QAccessible to JAAPI and the scripts we had already 
developed should work.  In the first approach, they'd have to write new 
scripts.

I should say that I am *not* an expert on this and whatever strategy we come 
up with should be vetted by someone who *does* understand it better than 
I. :)

-- 
Gary Cramblitt (aka PhantomsDad)
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]