[Kde-accessibility] Accessible objects without Atk dependencies

[Bill Haneman]

I'll let George speak for himself, of course, but my thought is that the
KDE ATs can (should?) choose between the following in the short term:

1) use the existing CSPI bindings and link to libspi/libcspi (pulling in
the GNOME stuff in anticipation that the dependencies incurred will be
reduced over time - and help us reduce them).  This would make the "KDE"
ATs use the shared backend when we as a community are ready to migrate,
or an alternate backend when one is available); or

2) use the AT-SPI python bindings, or have KDE AT developers write in
Python.

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.

I really think that writing an "at-spi lookalike", or KDE-flavored
bindings to an incompatible AT-SPI communications protocol, which would
then require some kind of runtime proxying, is a poor use of resources. 
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.

Of the two options, the python approach looks cleaner to me.  Python
experts may have more information on how to make the pyORBit AT-SPI code
"runtime loadable" (since I know .py modules can be dynamically loaded
with dynamic runtime resolution of symbols); it may be that this can be
done pretty easily without introducing any hard dependencies into the
KDEAccessibility linking process, or introducing gnome-specific client
API into the KDE apps.

regards

Bill

On Thu, 2006-03-30 at 00:56, Olaf Jan Schmidt wrote:
> [ George Kraft ]
> > Let's get the AT-SPI/ATK interfaces rich and mature first before venturing
> > off to re-tool which could cause regression.
> 
> Yes, we don't want to do anything that makes the existing implementation less 
> stable, and there is no need to do so if the current AT-SPI team works on 
> stabilisation while new people work on DBUS.
> 
> > Also, OMG designed Corba to bridge to other ecosystems; therefore, for 
> > the near term we should continue with the KDE to AT-SPI solution in
> > order to concentrate on the above.
> 
> I am not am not sure what you want to say with this.
> 
> Do you want to say that we should only work on the KDE to AT-SPI bridges, and 
> give up the plan to bridge from AT-SPI to KDE? This would mean we cannot use 
> AT-SPI in KDE-based assistive technologies and are forced to invent some 
> other API.
> 
> Or do you suggest to write CORBA bindings for KDE? This would likely be an 
> equal or even greater amount of work than using DBUS for AT-SPI.
> 
> Or do you want to imply that we should not write KDE-based assistive 
> technologies at all and contribute to the GNOME ones instead?
> 
> 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-accessibility