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 > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
