From: "Wang, Jing J" <[email protected]> > By adding some debug info in cally, I also noticed that Cally really > respond the pyatspi command and get right result on App side. But from > dbus-monitor info, seems the result is not passed to test script side at all. > So, the culprit is Pyatspi Cache. My question is, your fix will go to pyatspi > or Cally. Thanks
As I said, Mark Doffman has the idea of add a non-cache mode, and this would solve the problem already. *Anyway* the fact is that the cache is a good idea, and that Cally should work with it, in the same way that GAIL is working without problem, so my fix will go to Cally, as the cache is not being properly updated because the event listeners are not properly implemented. BR === API ([email protected]) > -----Original Message----- > From: Piñeiro [mailto:[email protected]] > Sent: 2009年10月15日 19:09 > To: Wang, Jing J > Cc: Wan, Shuang; [email protected] > Subject: Re: [clutter] Re: CALLY over ATSPI-dbus > > From: "Wang, Jing J" <[email protected]> > > > Piñeiro, > > Another problem I met is, with atspi-dbus, the example > > cally-atkcomponent-example only expose Application and Main Stage to > > outside, 3 rectangle button actors can't be detected. > > I found if I moved cally_util_a11y_init from the beginning to end of > > the source file (before clutter_main()). The 3 rectangle button actors can > > be detected successfully from pyatspi. > > Seems Cally can't realize the actors which are added after Cally Module > > is loaded. Is that what you mentioned "add_global_event_listener" issue? If > > yes, hope it can be fixed ASAP. > > Yes, is about the listeners, please take a look to the whole thread > opened by Shuang Wang: > > http://lists.o-hand.com/clutter/3241.html > > A summary: > > The problem here is *not* that Cally can't realize about the actors > added. If you ask directly to the Cally objects you will have the > correct values, and in fact, it emit the events about being added. > > The problem is that the listener is not supported, and as pytatspi > makes a cache of the current hierarchy tree (something really > sensible), updated with the event listener, the tree is not properly > updated because the missing event listener. > > And yes, this is a bug that I really want to solve. > > BTW: Mark Doffman commented that he is thinking in adding a > non-caching mode, that would solve the problem as well. > > BR > > > Thanks > > > > WangJing > > > > -----Original Message----- > > From: Piñeiro [mailto:[email protected]] > > Sent: 2009年10月13日 22:14 > > To: Wang, Jing J > > Cc: Wan, Shuang; [email protected] > > Subject: Re: [clutter] Re: CALLY over ATSPI-dbus > > > > From: "Wang, Jing J" <[email protected]> > > > > > Piñeiro, > > > Thanks for your help. I just tried the example --with-dbus, and it > > > works fine. > > > Next, another problem which may block Clutter GUI Auto Testing is How > > > to load Cally and atk adaptor module without apps modification, just as > > > the case of gtk application by --gtk-module to load external module. > > > > Yes, this is a know issue, check this bugs [1][2]. > > > > One option, although somewhat hackish, is keep using GTK_MODULES, and > > just keep installing the cally module in the gtk directory (as says > > [1]), and keep using GTK_MODULES. In some environments I used that, > > but it is clear that it is a hack-short-term solution. Something like: > > > > GTK_MODULES=cally:atk-bridge (with bonobo) > > GTK_MODULES=cally:spiatk (with DBUS) > > > > Although for the last one, I still need to fix this > > add_global_event_listener problem. > > > > > I heard you plan to integrate cally into Clutter, really? > > > > Hmm, I think that I don't understand you. Right now Cally is in the > > o-hand repository, like other clutter add-on (clutter-gst, etc). > > > > If you are talking about the run-time, Cally is as integrated with > > Clutter as GAIL is integrated with Gtk+. This have the advantage that > > you can load the a11y support only if you require that. > > > > You mean that you would like a deeper integration? > > > > BR > > > > [1] http://bugzilla.o-hand.com/show_bug.cgi?id=1737 > > [2] http://bugzilla.o-hand.com/show_bug.cgi?id=1738 > > > > === > > API ([email protected])
