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

[Bill Haneman <Bill Haneman Sun COM>]

Hi Daniel:

I am glad you are finding the architecture understandable and 
(potentially) useful, and would certainly like to help you resolve your 
blocking issues.

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.

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 am not sure I understand the problem with GSignalEmissionHook in 
python - but again, I'd be inclined to try and fix the blocker in ATK in 
coordination with the  pygtk+ maintainers.

Best regards,

Bill

Daniel Drake wrote:
> Hi,
>
> I'm attempting to add accessibility to a non-GTK application written in
> Python.  I guess this is more of a "here's how I'm getting on" feedback
> mail, but I'd appreciate any comments or clarifications on things I'm
> doing.
>
> After going from not knowing much about AT-SPI or accessibility in
> general a few days ago, I must say I'm impressed with the architecture
> which has been built, even if my understanding is not complete.
>
>
> My first attempt at this was interfacing with ATK. I figured that if I
> just tell ATK about all my widgets and their status, then we get
> accessibility 'for free'.
>
> After some experimentation I managed to write a small C sample app which
> defines the following classes:
>  1. A psuedo-widget GObject class
>  2. A AtkGObjectAccessible class to interact with the pseudo-widget
>  3. An AtkObjectFactory class to generate my AtkGObjectAccessible    
>     instances
>  4. An AtkUtil class to do the kind of things that GAIL does
>
> I built this with the long term goal that I'd be able to produce a
> GObject for every one of my custom widgets, with the accessibility
> objects built on top of that. Or alternatively skip the custom GObject
> and just build AtkGObjectAccessible instances on top of the custom
> widgets, if that is possible.
>
> Anyway - I built this prototype C app, and eventually managed to get
> dogtail to interface with my pseudo-widgets. Woohoo!
>
>
> Next, I decided to port my prototype C app to Python+pygtk, as the app
> I'm wanting to add accessibility to is a python app. I thought this part
> would be easy, however I ran into a few showstoppers early on due to
> pygtk's interface to ATK being incomplete:
>
>  1. The code generater does not know about GSignalEmissionHook so it
>     does not generate the add_global_event_listener() virtual function
>     for the atk.AtkUtil class, meaning that I can't write a gail   
>     replacement. This is potentially hard to solve because pygobject
>     mangles GSignalEmissionHooks internally, so passing one down from
>     AT-SPI's atk-bridge to glib's g_signal_add_emission_hook() poses
>     a challenge.
>
>  2. The definitions file does not include definitions for the virtual
>     function "get_parent" (and a few others) in atk.AtkUtil. These
>     virtuals are slightly odd in that they do not take the AtkUtil 
>     instance as the first parameter. pygtk currently offers no way
>     of generating code for these virtuals.
>
> I stopped at this point, although it would not surprise me if there were
> other showstoppers preventing me from implementing this stuff in python
> right now.
>
>
>
> I decided to change direction and thought about skipping the ATK and
> atk-bridge translation and simply adding an interface onto my app to
> talk to AT-SPI directly. pyspi looks like it will allow me to do this,
> so I research further. I can't find any website or documentation for
> pyspi, but I read up a little about pyrex and realise that the pyspi
> functionality is evident by reading the source (i.e. code is not
> automatically generated).
>
> Alas, understanding pyspi now requires me to understand the AT-SPI C
> API. There are docs for this one, but their purpose is unclear to me:
> are these docs detailing how an app can register with AT-SPI and say
> "i've got 3 buttons, 2 labels, and a frame", or do they detail how an
> accesibility app (e.g. screenreader) can say "give me the text from
> widget X on app Y", or both?
>
> Further confusion ensues when I look at the atk-bridge code and see it
> calling functions like spi_application_new() which are not mentioned in
> the API docs. That aside, spi_application_new() can't be used here since
> it deals in terms of AtkObjects and I've dropped the ATK idea. I'm left
> wondering how I might be able to create an application object so that I
> can register it, etc.
>
>
> The other option which I have not yet explored is to create a C library
> to make my app interact with ATK, and then a Python module bridge so
> that my app can talk to the C library. I'm no so keen on this though, I
> feel that this architecture has enough bridging already...
>
> Daniel
>
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>