After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 569427 - Atk should include a reciprocal relationship for NODE_CHILD_OF
Atk should include a reciprocal relationship for NODE_CHILD_OF
Product: atk
Classification: Platform
Component: atk
git master
Other All
: Normal major
: ---
Assigned To: Li Yuan
Li Yuan
Depends on:
Blocks: 554688 568158 569428 569430
Reported: 2009-01-28 07:13 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2009-11-09 03:18 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24

The patch I used in my tests. (1.14 KB, patch)
2009-01-28 07:15 UTC, Joanmarie Diggs (IRC: joanie)
committed Details | Review

Description Joanmarie Diggs (IRC: joanie) 2009-01-28 07:13:05 UTC
A screen reader providing access to an expanded item in a tree level is expected to include the number of items contained/displayed by that expanded node. In a tree which manages its descendants, the items contained in the expanded node are not children in the accessible hierarchy. Therefore, the only way to determine the number of *functional*/displayed children of an expanded node is to traverse the tree row by row looking for the NODE_CHILD_OF relationship and seeing if it happens to point to the expanded item under consideration. This is at best tedious and slow. In enormous trees in which most items are expanded, the system can grind to a halt. Literally.

Here are some sample numbers taken by using Orca and navigating amongst items in gconf-editor.

* "new way" == addition of a NODE_PARENT_OF relationship added to Atk, AT-SPI, and Gtk+/Gail and then used in Orca.

* "old way" == current state of affairs

* The second number is the number of immediate child nodes (i.e. the objects which exposed NODE_CHILD_OF for the object of interest.

* The final number if the number of seconds it took Orca to obtain the number of immediate child nodes.

new way 9 0.000730991363525
old way 9 23.5638701916
new way 2 0.000731945037842
old way 2 1.25174307823
new way 4 0.000732898712158
old way 4 0.757242918015
new way 1 0.000734090805054
old way 1 6.57471394539
new way 2 0.00074291229248
old way 2 5.74261903763
new way 1 0.000736951828003
old way 1 6.61324715614
new way 1 0.000760793685913
old way 1 38.6404290199

Personally I think the performance improvement is staggering and would ask that you seriously and immediately consider implementing such a relationship.

Thank you very much in advance for your consideration!
Comment 1 Joanmarie Diggs (IRC: joanie) 2009-01-28 07:15:06 UTC
Created attachment 127379 [details] [review]
The patch I used in my tests.

I don't care what you call the relationship. :-) Just implement it and let us know. This is the Atk patch I used when performing the tests I described in my opening report.
Comment 2 Willie Walker 2009-05-01 14:49:14 UTC
Li - what are your thoughts on this?  I think this would be a great addition for 2.28.
Comment 3 Li Yuan 2009-05-04 03:27:18 UTC
Sure. Will work on this.
Comment 4 Li Yuan 2009-11-06 08:25:54 UTC
Review of attachment 127379 [details] [review]:

Thanks very much for the patch.
Comment 5 Mike Gorse 2009-11-06 21:44:31 UTC
Should we move the new item to the end of the enum?  The git atk is currently not binary-compatible with 1.28.0.  I'm not sure off-hand if this violates any GNOME guidelines, but, either way, it worries me a bit, since it could cause subtle problems if someone upgrades atk without upgrading gail, and FF and OO would behave differently depending on which ersion of atk they were compiled against.
Comment 6 Li Yuan 2009-11-09 03:18:01 UTC
I have made the change. Thanks for your remind Mike.