GNOME Bugzilla – Bug 474504
Should return minimally-functional AtkObject instances when there is no renderer in column
Last modified: 2007-11-19 09:58:52 UTC
gail_tree_view_ref_child should return minimally-functional AtkObject instances when there is no renderer in column.
I'm wondering if this minimally-functional AtkObject could solve the problem in bug 395781 (aka bug 474504). In that instance, the column serving as the expander column lacks a cell renderer and hence NULL is returned. The expander-related information is not given to any other column and hence it is lost/not-exposed to ATs.
Sorry for the spam. The aka bug is bug 407647.
I am not sure. If we add the relationship in the minimally-functional AtkObject, can Orca find the tree level of item? I think Orca get the level by calling util.getNodeLevel() on a cell in the second column (the one contains real cells).
Li, sorry for not being clear. There are really two issues that should be addressed in Orca for bug 407647 (only one of which is stated): 1. Indicate the level 2. Indicate if the current row is expanded or collapsed (assuming it is expandable/collapsible) We have no way of addressing #2 because the expander column has no cell renderer and thus STATE_EXPANDABLE and STATE_EXPANDED are not exposed for any items.
Just a ping to see where this bug stands. Thanks!
I made a patch to return a minimally-functional AtkObject. Also I set STATE_EXPANDABLE and STATE_EXPANDED to its state if necessary. Have a little test with accerciser and works fine. I wish the patch can fix this bug and bug 395781 both. How can I make Orca tell me if a cell is expandable? Or can someone help me to test this patch with Orca? Thanks.
Created attachment 99131 [details] [review] patch
> How can I make Orca tell me if a cell is expandable? Given just regular ol' cells that don't require minimally-functional AtkObjects be created on their behalf, Orca should automatically tell you the state when you arrow to the cell. It should also tell you the state of the selected item when it changes. And, finally, by default it should tell you the number of child nodes in an expanded item when you arrow to it. Given the Pidgin buddy list.... Your patch works like a charm in terms of exposing the info we need. Thanks!! Because the new object resides in a hidden column that the table denies even exists, we needed to give Orca's Pidgin script some smarts. I've attached a patch to the Orca bug (http://bugzilla.gnome.org/show_bug.cgi?id=407647#c2). It's a first attempt, but it seems to work. Thanks again!!
Li, I did notice one area that doesn't seem to be quite working. With your patch applied, try the following using Accerciser's event monitor and Pidgin: 1. Be sure your buddy list has a group as the first row and that there are items visible in the group. 2. Arrow to that first row and use Shift+Right/Shift+Left to expand/collapse it. Expected results: Among the events would be an object:state-changed:expanded. Actual results: We are not getting an object:state-changed:expanded. Note that we do seem to get the expected events for other groups. It's just the first row where it's missing. Also note that the state is getting updated correctly for that row; we're just not being notified that the update has occurred.
That's weird, I see the event when I following your steps. There are many groups in my pidgin, and the first row is a group.
Hmmmm.... Not sure what to tell you then. Maybe it's something odd in my setup. I do think this patch is a great improvement to the current situation regardless.
Created attachment 99323 [details] [review] new patch
I tried on another machine and it works fine. So I committed the patch. If there is any problem, please file a new bug. Thanks! BTW, I would close bug 395781 also.