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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]