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 639479 - Document recommended AtkTable hierarchy
Document recommended AtkTable hierarchy
Product: atk
Classification: Platform
Component: atk
Other All
: Normal enhancement
: ---
Assigned To: ATK maintainer(s)
ATK maintainer(s)
Depends on: 651343
Blocks: 638537 651358
Reported: 2011-01-13 23:23 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2021-06-10 11:25 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Joanmarie Diggs (IRC: joanie) 2011-01-13 23:23:43 UTC
Our table hierarchy doesn't jive with what Atk implementors think it should be. So the implementors start getting creative and do things like:

--> Table
      --> List item
            --> Table Cell
            --> Table Cell
      --> Table cell


1. List items are children of lists; they are not children of tables. :-)

2. The above structure is not consistent.

3. ATs have no clue what might be awaiting them in a table and have to be prepared for anything. ;-)


1. Give the implementors the roles they want so that they stop being creative. :-) Based on the above example, that would mean adding at least a new role for table rows. We might wish to consider one for columns as well. But rather than just deciding, I'd like to get the input of the implementors so we can all agree on a hierarchical structure for tables that is comprehensive and easily understood.

2. A document for implementors that clearly states what the structure should be (e.g. if we're going to start having table rows exposed to us, that's fine. But then use them all the time rather than just on those occasions when a particular row has an attribute which needs exposing.)
Comment 1 Li Yuan 2011-05-09 11:46:36 UTC
Do you mean the situation that there are more than on cell renderer in one column? In this case "List item" is a GailContainerCell.
Comment 2 Joanmarie Diggs (IRC: joanie) 2011-05-28 19:38:45 UTC
The hierarchy agreed upon at the ATK Hackfest is:

 -> Table Row (always exposed ATK_ROLE_TABLE_ROW)
    -> Table Cell
    -> Table Cell
 -> Table Row
    -> Table Cell
    -> Table Cell
Comment 3 Benjamin Otte (Company) 2011-06-23 14:42:25 UTC
So I've been looking at the GailTreeView code for a bit and a big problem seems to be trees. GailTreeView tries to flatten the tree of a treemodel into a list, so that it can implement AtkTable. If you have a tree like the tree sidepane in nautilus, that thing is showing your whole filesystem, like so (note that you can click on each '+' to expand more of the tree):
- File System
  + bin
  + boot
  + cgroup

Now, what AtkTable wants is a list of rows, so GailTreeView flattens things. It does that by first expanding the whole tree, and then flattening it, so it looks like this:
- File System
- bin
- boot
- efi
- redhat
- extlinux
- grub
- lost+found
- cgroup
I hope you can see where this is going: It's becoming a huge list. And not only that, the index in the list does not in any way correspond with the position in the tree. So operations like get_row_at_index() get very complicated - index 8 corresponds to subitem 3 of subitem 1 of the tree root (/boot/lost+found) while index 9 corresponds to the subitem 2 of the root of the tree (/cgroup). Also, you need to really crawl the whole hard disk to expand the tree, which is very slow in itself. (GTK avoids that by just not expanding the folders it doesn't care about).

So an idea for implementing a tree would be to allow rows to have other rows as children and implement AtkTable themselves. That way, a tree could be implemented like so (with the example from above in brackets)

 -> Table Row (File System)
    -> Table Cell
    -> Table Cell
    -> Table Row (bin)
       -> Table Cell
       -> Table Cell
    -> Table Row (boot)
       -> Table Cell
       -> Table Cell
       -> Table Row (efi)
          -> Table Cell
          -> Table Cell
    -> Table Row (cgroup)
       -> Table Cell
       -> Table Cell

No idea how well ATs would like such a somewhat complex tree layout though.
Comment 4 Alejandro Piñeiro Iglesias (IRC: infapi00) 2011-06-23 17:04:55 UTC
While discussing that on IRC, Joanie mentioned that it would be good to check how IA2 manages this kind of things (as we already concluded that maintaining a IA2-ATK sync would be good)
Comment 5 Joanmarie Diggs (IRC: joanie) 2011-06-23 17:17:49 UTC
I looked at the IA2 docs and also poked the mozilla a11y guys in #accessibility. It seems that IA2 implements a table interface on the table itself, and a table cell interface on an individual table cell.
Comment 6 André Klapper 2011-06-23 22:06:05 UTC
[Mass-reassigning open atk bug reports for better trackability as requested in .
If you have watched the previous assignee of this bug report as a workaround for actually getting notified of changes in atk bugs, you yourself will now have to add atk-maint@gnome.bugs to your watchlist at the bottom of to keep watching atk bug reports in GNOME Bugzilla.
Sorry for the noise: Feel free to filter for this comment in order to mass-delete the triggered bugmail.]
Comment 7 Alexander Surkov 2011-06-24 08:00:55 UTC
While comment #3 concerns hierarchy then it makes sense to refer to examples rather than IA2 spec because afaik IA2 says nothing about hierarchies.

ARIA allows flat treegrids only but iirc the reason is keep life easier for AT clients and servers. 

XUL has treegrids, Gecko creates flat a11y hierarchy for them. XUL trees can be really big (for example in Thunderbird's mail list). I can't say there's no performance issues but it works.

Benjamin, technically you don't need to crawl whole hard disk because nobody requires your to create a flat tree at once. You can append/remove items when user expand/collapse the tree. Though that could be perf problem too since that requires you to change accessible tree a lot.

In short I don't really have problems to introduce new hierarchy and don't have other objections than it's one more hierarchy that AT must support. But if proposed hierarchy due to some reason is much more preformant than flat one then I vote for it.

I'd suggest to cc Frederic, since we had a good conversation at ATK hackfet about tables.
Comment 9 André Klapper 2021-06-10 11:25:34 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of atk, then please follow
and create a ticket at

Thank you for your understanding and your help.