Re: [g-a-devel] Interfacing a non-GTK application with AT-SPI

[Daniel Drake <ddrake brontes3d com>]

On Wed, 2006-12-13 at 21:59 +0000, Bill Haneman wrote:
> I would encourage you to proceed with the ATK/python approach.  The 
> PyORBit bindings for at-spi are client-centric, and libspi.so is mostly 
> a wrapper for ATK, as you have discovered.  Other implementations of 
> AT-SPI services are possible and encouraged, but you'd have to 
> substitute your own implementations for the ones which proxy ATK - this 
> is likely to be more trouble than using ATK directly.  Also, using ATK 
> directly is more in line with the primary intention of ATK vs AT-SPI.

Thanks for the explanation.

> The python binding issues for AtkUtil functions are an annoyance - 
> AtkUtil is a singleton class, which is why it doesn't take an object 
> instance as first parameter.  Since doing what you are doing is 
> something we want to support, I would not at all object to adding 
> AtkUtil API which _does_ take an object instance as first parameter, 
> especially since we are only dealing with two or three methods of 
> importance.  Alternatively, you could hand-code your own AtkUtil python 
> object using C, I think...

I don't think modifying the ATK API is the right approach here, instead
pygtk should be fixed. This is relatively easy to do (I think) by adding
a static-virtual class of functions. However there are other
showstoppers preventing AtkUtil being implemented there, which don't
seem so easy to fix.

I wrote my AtkUtil implementation in C with the aim of doing the rest in
Python, but I ran into some problems. AtkUtil must return the root node
and this requires that AtkUtil must be able to construct it (I think),
which means it must know about the GType of that node. And then I get
into this horrible dependency chaining problem.

I think this could be fairly easily avoided if I knew how to reference a
Python-defined GType from linked in C code, and vice-versa. Right now I
have proceeded writing a Python module in C as a bridge, and then all of
the accessibility abstraction classes in C. I am relatively happy with
this but do plan to figure out the GObject interaction and port most of
the classes to Python in the near future.

Thanks for your help!
-- 
Daniel Drake
Brontes Technologies, A 3M Company