Re: [g-a-devel] GTK and ATK

[Li Yuan <lee yuan oracle com>]

于 2011/5/11 2:38, Federico Mena Quintero 写道:
> ATK is "duplicated" interfaces.  It needs to be kept in sync with the
> rather axiomatic interfaces provided by at-spi.  It has to deal with
> messy details like GTK+'s reference counting (and who knows if at-spi is
> amenable to that kind of detail).
By implementing ATK interfaces, applications don't need to care about 
the IPC stuff. Or every toolkit will need to do a lot work when we 
transfer from CORBA to D-Bus, and to another IPC in the future.

> One problem may be that at-spi sometimes wants to be tightly-bound to
> things that are far away from it, and that's bad design.
>
>
>
> Maybe at-spi needs to be more stateless.  I don't know exactly how that
> would work, but maybe it's about letting you reconstruct your "view" of
> an accessible application easily, in a couple of D-Bus calls, instead of
> doing a million calls just to re-sync everything.  Take a widget
> hierarchy and its available accessible interfaces, and push the entire
> thing as a JSON blob?  Use paths to refer to widgets (or accessible
> objects), like SomeApp/MainToolbar/SaveButton instead of querying each
> sub-hierarchy by hand just to get a volatile object reference?  I don't
> know.
I don't know how accessibility is going to work in the way you suggest too.

> Maybe the D-Bus stuff on the client side should be maintained directly
> inside GTK+?  (Does anyone *call* ATK directly to implement an
> accessibility dongle, or do they always go through D-Bus?  Why does ATK
> need a public API - can't it just be basically the "structs" for the
> GTypeInterfaces and as little boilerplate as needed to make those
> interfaces implementable?)
You don't want to modify all toolkits' accessibility implementation when 
we switch to another IPC. This is what ATK doing - letting toolkit's 
accessibility implementation separate from IPC.


Li