GNOME Bugzilla – Bug 639479
Document recommended AtkTable hierarchy
Last modified: 2021-06-10 11:25:34 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 Problems: 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. ;-) Solutions: 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.)
Do you mean the situation that there are more than on cell renderer in one column? In this case "List item" is a GailContainerCell.
The hierarchy agreed upon at the ATK Hackfest is: Table -> Table Row (always exposed ATK_ROLE_TABLE_ROW) -> Table Cell -> Table Cell -> Table Row -> Table Cell -> Table Cell
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 - 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 -> 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.
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)
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.
[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 . PLEASE NOTE: 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 https://bugzilla.gnome.org/userprefs.cgi?tab=email 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.]
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.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org 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 https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.