Tutorial

« Tree and List Widget Tree Selections »

The TreeModel interface defines a generic tree interface for use by the TreeView widget. It is an abstract interface, and is designed to be usable with any appropriate class. The programmer just has to derive a new class that multiplely inherits from this interface for it to be viewable by a TreeView widget.

The model is represented as a hierarchical tree of strongly-typed, columned data. In other words, the model can be seen as a tree where every node has different values depending on which column is being queried. The type of data found in a column is determined by using the GType system (i.e. G_TYPE_INT, GTK_TYPE_BUTTON, G_TYPE_POINTER, etc.). The types are homogeneous per column across all nodes. It is important to note that this interface only provides a way of examining a model and observing changes. The implementation of each individual model decides how and if changes are made.

In order to make life simpler for programmers who do not need to write their own specialized model, two generic models are provided - TreeStore and ListStore. To use these, the developer simply pushes data into these models as necessary. These models provide the data structure as well as all appropriate tree interfaces. As a result, implementing drag and drop, sorting, and storing data is trivial. For the vast majority of trees and lists, these two models are sufficient.

Models are accessed on a node/column level of granularity. One can query for the value of a model at a certain node and a certain column on that node. There are two structures used to reference a particular node in a model. They are the TreePath and the TreeIter (iter is short for iterator). Most of the interface consists of operations on a TreeIter.

A TreePath is essentially a potential node. It is a location on a model that may or may not actually correspond to a node on a specific model. The TreePath class has two methods that can return the path either as a String or as a vector of integers. The string form is a list of numbers separated by a colon. Each number (a zero-based index) refers to the offset at that level. Thus, the path "0" refers to the root node and the path "2:4" refers to the fifth child of the third node.

By contrast, a TreeIter is a reference to a specific node on a specific model. It is a generic class that represents an integer and three generic pointers. These are filled in by the model in a model-specific way. One can convert a path to an iterator by calling Gtk::TreeModel::get_iter(). These iterators are the primary way of accessing a model and are similar to the iterators used by TextBuffer. They are generally statically allocated on the heap and only used for a short time. The model interface defines a set of operations using them for navigating the model.

It is expected that models fill in the iterator with private data. For example, the ListStore model, which is internally a simple linked list, stores a list node in one of the pointers. The TreeModelSort stores an array and an offset in two of the pointers. Additionally, there is an integer field. This field is generally filled with a unique stamp per model. This stamp is for catching errors resulting from using invalid iterators with a model.

The life cycle of an iterator can be a little confusing at first. Iterators are expected to always be valid for as long as the model is unchanged (and doesn't emit a signal). The model is considered to own all outstanding iterators and nothing needs to be done to free them from the user's point of view. Additionally, some models guarantee that an iterator is valid for as long as the node it refers to is valid (most notably the TreeStore and ListStore). Although generally uninteresting, as one always has to allow for the case where iterators do not persist beyond a signal, some very important performance enhancements were made in the sort model. As a result, the TREE_MODEL_ITERS_PERSIST flag was added to indicate this behavior.

To help show some common operations of a model, some examples are provided. The first example shows three ways of getting the iter at the location "3:2:5". While the first method shown is easier, the second is much more common, as you often get paths from signal handlers.

The iter is an uninitialized TreeIter. In the first method path is a TreePath and in the second method path is the string representation of a TreePath. Both methods set iter to a valid iterator pointing to the specified path, if it exists and returns true. Otherwise, iter is left invalid and false is returned.

There are three ways of getting the iter pointing to a location. The first two use the above get_iter() methods:

The third method involves walking the tree to find the iterator. To do this you need to use the Gtk::TreeModel iterate_nth_child() method:

The iter is an uninitialized TreeIter, parent is the TreeIter to get the child from and n is the index of the desired child. This method sets iter to be the child of parent, using the given index. The first index is 0. If index is too big, or parent has no children, iter is set to an invalid iterator and false is returned. The parent will remain a valid node after this method has been called. As a special case, if parent is null, then the nth root node is set.

To find an iterator by walking the tree you would do something like this:

This second example shows a quick way of iterating through a list and getting a string and an integer from each row. The model used is a ListStore with two columns: a string column and an integer column.