Olaf Jan Schmidt wrote:

>Hi Bill!
>
>[ Bill Haneman ]
>  
>
>>>I removed the first possibility, since the extention of Qt Accessibility
>>>has already been made.
>>>      
>>>
>>Well, I disagree with that.  We should list all possibilities even if
>>some decisions seem to have been made, otherwise I don't think we can
>>have a clear discussion about the decision making process. If #1 has been
>>rejected, it should still be discussed and the reasons for rejecting it
>>documented in the Wiki. 
>>    
>>
>
>I listed the reasons in the section of background facts:
>* The work to extend Qt Accessibility has already been made.
>* Qt Accessibility is portable.
>
>I could add:
>* All KDE widgets are subclasses of Qt widgets and inherit Qt Accessibility 
>support.
>* Qt Accessibility offers everything that we need for AT-SPI support, so it 
>doesn't seem to make sense implementing atk support twice.
>
>But I am probably missing something here. What exactly would be the technical 
>difference between #1 and #2?
>  
>
In my email, #1 had Qaccessible->ATK, then the atk-bridge was dll'ed at 
runtime to export AT-SPI.
This would mean KDE didn't need to touch any IPC code at all at this 
stage, and the same AT-SPI implementation and bridge was used everywhere 
on both desktops.  But also in my email ATK would become an officially 
blessed API for KDE accessibility; if you don't want glib then I agree 
that this probably is not what you want.

You seem to be saying that part of #2 has already happenned - 
QAccessible has been extended to provide the information needed by ATK.  
Therefore a QAccessible-to-atk bridge can already be written and 
combined with the existing atk-bridge module (if the mainloop 
integration problem can be solved). 

In that case there are still two ways that KDE could make good use of 
the existing AT-SPI implementation in the short-to-medium term; you 
could write a QAccessible->ATK bridge (which is pretty much what mozilla 
did with nsiAccessible->ATK, and nsiAccessible is very similar to 
QAccessible), and use atk-bridge (assuming, again, that the mainloop 
issue is solvable).  Then when we have a good solution for AT-SPI over 
D-Bus that has good performance etc., the atk-at-spi CORBA bridge gets 
swapped out for the new atk-at-spi D-Bus version, for all applications 
across both desktops.

In situations where the existing CORBA solution just wasn't workable, 
such as the embedded situation, the atk-dbus bridge could be used 
sooner, while performance issues and things like network and root access 
were being worked out.  And of course the "double bridge" from 
QAccessible could eventually be reduced to a single QAccessible->DBus 
bridge as well, but it could happen when time and resources permit.

Bill

>Olaf
>
>  
>

_______________________________________________
kde-accessibility mailing list
kde-accessibility@kde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility