[Kde-accessibility] Dependencies

[Bill Haneman]

On Wed, 2002-11-27 at 00:26, Olaf Jan Schmidt wrote:
 
> Hi!
> 
> As there was some talk of having GNOME dependencies in kde-core at 
> compile-time, I was wondering whether we are talking about different 
> approaches here. My understanding was that a simple generic KDE 
> accessibility framework (call it KATK if you want) might be bridged to 
> ATK or AT-SPI in a library which is independent of any other KDE code.

Hi Olaf:

This could be done without creating a KDE accessibility framework (see
my email to Pupeno).

> While it would be a good idea to base Qt itself on ATK and thereby make 
> all Qt and KDE applications accessible without much other work, this is 
> beyond our scope, so we will need some Qt-ATK bridge anyway - either in 
> kde-core, or better in an optional package.

I think that we really need to implement nearly all of ATK in order to
work with assistive technologies.  Something that 'appears' to support
AT-SPI but actually doesn't provide complete or correct implementations
of the APIs could be a real problem, and would not be likely to work
well.
 
> There is already some functionality in Qt and DCOP which we could extend 
> to create a very simple KATK. We would not need to implement a complete 
> accessibility framework all at once, as making KDE application export 
> their GUI elements to AT-SPI would already be a huge step. The question 
> how KDE applications could get other information about other applications 
> could be addressed later. Our first goal should be just to make sure that 
> KDE applications are seen by AT-SPI, so assistive technologies work also 
> with KDE applications.

I disagree, it's very important to get the framework drafted correctly
at the outset.  There is very little in ATK that is not of vital
importance to assistive technologies; if you want KDE applications to
work with assistive technologies you should, in my opinion, at least
have the whole infrastructure/API in place from the beginning, even if
some widgets don't implement all of the useful interfaces at the outset.
 
> The properties of any named QObject can already be accessed via DCOP. The 
> only problem with KDE objects like menus is that often some of their 
> sub-objects are not named, so they are invisible for DCOP (which could be 
> changed).

This would certainly need to be changed, or at least the KDE
accessibility module(s) would need to know enough about the internal KDE
object APIs to get the information outside of DCOP.

Our conclusion when we looked before was that DCOP itself did not
provide enough structured information to serve as a good accessibility
API or mechanism on its own, but it could be used internally by the KDE
accessibility code that exports ATK.  In other words the KDE briding
code could use DCOP and Qt APIs to get the necessary widget information,
and then repackage it into AtkObjects; the Qt and widget libraries would
not need to know anything about Atk or Glib in this scenario.
 
> Another strategy would be to extend QAccessibleObject in cooperation with 
> TrollTech, so that the properties of all QObjects can be reached, not 
> just the original Qt objects.

This sounds like a good approach, and would avoid "yet another layer"
for Qt objects.  Bridging from QAccessible to some 'other' KDE
accessibility API and then to ATK and then to AT-SPI seems needlessly
complex.  Making QAccessible the basis for the internal accessibility
API would alleviate the need for at least two of these layers, though I
would recommend bridging to ATK and not AT-SPI for the reasons that have
already been discussed.

in other words:

[[QAccessible].extensions]->(internal bridging library)->ATK->...

...->("atk-bridge" from GNOME)->AT-SPI->(assistive technology)
 
> Anyway, what we would need to add for an KATK solution would be 
> information about which QObjects are currently shown in which window, 
> where the cursor currently is, and a notification of any changes.

Yes, there are vital pieces of information.  A lot more than this is
required too; for a summary, see the ATK API documentation.  For
instance you need to be able to report text attributes and the bounding
boxes of text glyphs and characters.

The only interface which might be optional would be
AtkStreamableContent.  Some interfaces, such as 
AtkTable, would only be needed by table and list widgets, and
AtkHypertext would only be needed by browser content panes, help
widgets, and other hypertext-containing objects.

AtkObject, AtkComponent, AtkText, and AtkSelection would be a good
starting point.  One thing that's important is that if a widget
advertises an interface, it's expected to implement all the methods in
it except possibly those that are allowed to return a boolean FALSE on
failure.
 
best regards,

Bill

> What else would we need to implement some basic KATK?
> 
> Olaf.
> 
> - -- 
> Olaf Jan Schmidt, KDE Accessibility team
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAj3kERwACgkQoLYC8AehV8fu1gCfaNwgnDKbCaPcryjQYKGyAfib
> Tr4AnjYR0UkN/bUH164KWZXe8OfxYedv
> =tyhU
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-accessibility