Re: desktop-devel-list digest, Vol 1 #2110 - 16 msgs

[Bill Haneman <Bill Haneman Sun COM>]

Jamesh said:

> Without knowing what the Accessible::Document interface would look 
> like, I can't say whether at-spi would be any better or worse. The 
> current interfaces appear to only mirror the GUI (view) portion of an 
> app, which is of limited use for scripting. There are probably other 
> options available too. My point is that telling people to use one 
> interface for scripting small programs, and a completely different API 
> for scripting their larger office programs seems a bit confusing. James. 


One thing to remember is that at-spi is designed to expose UI, which 
isn't necessarily "GUI".  So the at-spi interfaces can easily be used, 
with only trivial extension, to expose a non-graphical interface.  Doing 
this in a reasonably consistent way across applications would require 
some planning, but I don't think the at-spi interfaces would have to be 
abused in order to make this work.

In general, assistive technologies only expose AT-SPI interfaces that 
_are_ visible/mapped somehow to the GUI, but this is only to prevent 
hidden objects from being exposed to users inappropriately.  This also 
means that if 'hidden' at-spi implementors are added in a consistent way 
to applications, possibly with the addition of one or two ATK/at-spi 
STATE values or conventions, such scripting support would not conflict 
with existing accessibility features.  Such an approach would probably 
enhance accessibility in some situations, as has already been suggested.

One reason why we didn't tie at-spi explicitly to graphical UI 
components only is because some applications and desktop services may 
present "interfaces" that aren't graphical (for instance, audio device 
control via acme).  It seems to me that the sorts of desktop services 
that need to be scriptable fall nicely into this category.

- Bill