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

List:       kde-accessibility
Subject:    Re: [Kde-accessibility]
From:       Olaf Jan Schmidt <ojschmidt () kde ! org>
Date:       2006-03-30 10:13:18
Message-ID: 200603301213.18400.ojschmidt () kde ! org
[Download RAW message or body]

[ Bill Haneman ]
> The above solutions mean that explicit GNOME API is kept out of the KDE
> ATs, and the GNOME libs are only pulled in through linking.  With some
> clever use of dynamic loading or module preloading the dependencies
> could be made entirely runtime-optional.

This is an interesting approach. We would only use a small part fo the AT-SPI 
functionality, so we could have some very simple DBUS-based fallback solution 
if ATSPI is not installed (without claiming to fork AT-SPI itself).

> It would require a lot of proxying/wrapping and at least one new daemon
> to relay information bidiretionally between AT-SPI/CORBA and
> AT-SPI-CLONE/DBUS; it's not the best way to ensure interoperability.

The deamon would not need to be bidirectional, because we can use the Qt-ATK 
bridge for the other direction. And it would not need to bridge the whole 
AT-SPI functionality to DBUS, only the few functions that we need.

> Of the two options, the python approach looks cleaner to me.

I agree, but some of the applications already exist as C++ code.

Olaf

-- 
Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards 
accessibility networker, Protestant theology student and webmaster of 
http://accessibility.kde.org/ and http://www.amen-online.de/
_______________________________________________
kde-accessibility mailing list
kde-accessibility@kde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility
[prev in list] [next in list] [prev in thread] [next in thread]