GNOME Bugzilla – Bug 145082
Cannot gok UI grab to evolution compose pane
Last modified: 2009-08-15 18:40:50 UTC
If there is bonobo control in a bonobo container, GOK UI grab do not work for the control
Created attachment 29058 [details] [review] test case patch it to libbonoboui/samples. Then make install. and run sample-control-container.
Build the attatched simplified testcase and start GOK, try the UI grab feature. And you will find UI grab can only find the button, but cannot grab to gtkentry in bonobo control.
As noted in bug #145078 the test program does not build correctly.
Yuedong, If you are familiar with at-poke, can you report at-poke's ability to access this control?
Created attachment 29454 [details] at-poke the test program
Hi Padraig, that maybe a bug in the test program. Because it happens to work on my rh linux box, so I missed it. Please fix it as you do in #145078. Thanks
David, About the attached at-poke image: focused item in the image is the bonoboControl.
Yuedong, Looking at the right side of the at-poke window, it seems to think that a panel is focussed. Is this the correct role that you are expecting? GOK does not display panels in UIGrab, and especially one's that do not have an accessible name/label.
York: your example from at-poke doesn't seem to be very relevant to the Evolution problem which started this discussion. Can you post an at-poke screenshot from Evolution? IN order for GOK to show the text entry field, it must implement AtkEditableText and it should preferably have a name as well. It also needs to be SENSITIVE and ENABLED, as well as react to AtkComponent_grabFocus() calls.
Created attachment 29637 [details] at-poke evolution composer
The composer area has already implemented the AtkEditableText interface. So I think the problem is similar to the test case I've attached. I will add a name and check the AtkState to see if what is the result.
Created attachment 29644 [details] at-poke evolution composer the focused item is the compose area
York: The screenshot shows the wrong focussed item; the text entry (not the scroll pane) should be focussed.
Hi bill, In the 2nd attachement, the focused item is the compose area, not scroll pane. Compse area is actually a gtkhtml widget. The a11y object of it has AtkText or other type of child. This how it orgnized in composer.
York: I looked at the compose widget's state: it does not include SENSITIVE. See my comment #9 above, the text entry must have state SENSISITIVE in order for GOK to expose it in UI Grab.
Note that the GtkTextView widgets from gtk-demo have state SENSITIVE when examined with at-poke.
This is looking less and less like a gnome bug, and more like something evolution-specific.
Yes, it is not gnome bug. sorry for spam, close it.
York: do we have a fix for this yet?
York: is there a related bug logged against evolution? If so please post it here.
I will fix the bug soon. My proposed solution is to add a "grab focus" action interface to the a11y object for gtkhtml editor widget. In my test env, I can grab focus to the compose area by GOK now. http://bugzilla.ximian.com/show_bug.cgi?id=61995
The link above is the bug I just filed on evolution about this.
Great, thanks for taking care of this.
York: I don't understand your comment #21 above - but it's not clear to me that it is correct. Adding a 'grab focus' action will NOT solve the issue for GOK, since GOK doesn't know that it has to look for such an interface.
Please see my comments on ximian bug #61995