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

On 30/03/04 01:27, Bill Haneman wrote:

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.

I don't doubt that the accessibility interface could be used to expose the "model" of an application.

But if we are considering AT-SPI as a scripting interface, we need to look at ease of implementation. I am not convinced that it would be any easier for an app author to maintain a tree of AtkObjects representing their document model compared to exposing it via custom CORBA interfaces, DBus, etc.


Email: james daa com au

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