Re: Getting at tree information in ATK

["Padraig O'Briain" <Padraig Obriain Sun COM>]

This is a writeup of a discussion we had about a accessible implementation of
a TreeTable.

A TreeTable is a combination of a Tree and a Table -- a component capable of 
both expanding and collapsing rows, as well as showing multiple columns of 
data.  Think of Macintosh Detail Directory View or see 
http://java.sun.com/products/jfc/tsc/articles/treetable1/index.html
In GTK terms, it is a GtkTreeView with a GtkTreeStore as model; if we had a 
GtkListStore as model we would have a standard table.

We assume that, if the model for a GtkTreeView is a GtkTreeSTore, one column 
is an expander column, i.e. this is the column the expander arrow is drawn at 
for rows which are expandable. If this assumption were not true the user would
have no visual cue to expand a row. A cell is either a toplevel cell or an 
expanded cell. A toplevel cell is in a row which is displayed when no rows
are expanded. An expanded cell is a cell in a row which is displayed only when
another row is expanded.

We will defined a new role ATK_ROLE_TREE_TABLE. The accessible object for the
GtkTreeView, which I will call a GailtreeView, will have the role 
ATK_ROLE_TREE_TABLE if the model for the GtkTreeView is a GtkTreeStore. A
GailTreeView will implement AtkTable. All the cells, including those in 
expanded rows, are children of the GailTreeView. We will define a relationship 
for cells in the expander column to identify the cell whose expansion cause the 
cell to be displayed. The name of the relation will be 
ATK_RELATION_NODE_CHILD_OF. For a toplevel cell the value of the relation will
be the GailTreeView. We can use to identify the expander column as exactly
one cell in the first row will have this relation defined 

If we wish to support changing the expander column we would need a new 
function atk_table_set_expander_column(AtkTable, int). We would also need to 
define a signal "change_expander-column" if we wish to be informed if the 
expander column is changed. I will not add this unless there is a consensus for 
it.

Each toplevel or expanded cell in the table has an index. There are two options 
for the index value. In the first option the index will be 
column + row * number_of_columns. If a cell is not displayed because a row is 
collapsed then the cell will not have an index. So expanding a row will have 
the effect of adding cells (children) to the GailTreeView and collapsing a row 
will have the effect or removing cells (children) from the GailtreeView. In the
second option the first set of index values will be for cells in toplevel rows,
the next set for cells displayed when a toplevel row is expanded and so on.
In this case the index value will not change when rows are expanded or 
collapsed. I think that the second option is more attractive.

The relations ATK_RELATION_NODE_CHILDREN and ATK_RELATION_NODE_PARENT, which
were proposed to support cells which are compound objects in a TreeTable are 
no longer required, as the normal parent/child relationship can be used to 
access the cells which are compound objects.

Padraig


> 
> 
> > 
> > To support trees in ATK, I was thinking of defining the relations
> > ATK_RELATION_TREE_NODE_CHILDREN and ATK_TREE_NODE_PARENT. 
> > 
> > These would allow us to specify for each accessible which is in a tree, i.e. 
> > GtkTreeStore, the children of a node and the parent node of a node.
> > 
> > These would be used instead of parent/child to navigate a tree.
> > 
> > One problem with this approach is that we would have to create accessible 
> > objects for each child cell when the user wished to investigate how many 
child 
> > nodes a node has.
> > 
> > The alternative is to try and use the parent/child relationship to navigate 
> the 
> > tree.
> > 
> > To achieve this I think we need the following:
> > 
> > 1) We need to deal with columns in a GtkTreeView which have more than one 
> > renderer. We will assume that there are not two renderers of the same type.
> > Consider the case where the column contains a pixbuf and text. Instead of 
> > exposing the cells objects corresponding to the pixbuf and the text as 
> children 
> > of the containercell the containercell will implement all the interfaces 
that 
> > its children may implement and call through to the first child which 
> implements 
> > the interface.
> > 
> 
> Rather than make the assumption that all the accessible information can be 
> exposed without getting at cell objects in the containercell I propose to 
define 
> two new relations ATK_RELATION_NODE_CHILDERN and ATK_RELATION_NODE_PARENT 
> to allow access to the cell objects.
> 
>  * ATK_RELATION_NODE_CHILDREN: Indicates an object is a node in a tree or 
table 
> and a compound object which more than one subobject
>  * ATK_RELATION_NODE_PARENT: Indicates an object is a subobject of a compound 
ob
> ject which is a node in a tree or table.
> 
> > 2) We do not assume that all the cells in a table are children of the table. 
> For 
> > a GtkTreeStore only the top level cells will be children of the table. For a 
> > GtkListStore all the cells will be children of the table.
> > 
> > 3) The function atk_table_get_index_at() may return an invalid index, i.e. 
-1, 
> > for cells which are not children of the table. This implies that the cell at 
> the 
> > specified (row, column) is a child of an expandable cell.
> > 
> > Padraig
> >