Signals

Description

The GtkTreeModel interface defines a generic tree interface for use by
the GtkTreeView widget. It is an abstract interface, and is designed
to be usable with any appropriate data structure. The programmer just
has to implement this interface on their own data type for it to be
viewable by a GtkTreeView 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 (ie. 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 — the
GtkTreeStore and the GtkListStore. 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 GtkTreePath and the GtkTreeIter[4]
Most of the interface consists of operations on a GtkTreeIter.

A path 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 GtkTreePath struct can be converted into either an array of
unsigned integers or a string. The string form is a list of numbers
separated by a colon. Each number 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 GtkTreeIter is a reference to a specific node on a
specific model. It is a generic struct with 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_tree_model_get_iter(). These iterators are the primary way of
accessing a model and are similar to the iterators used by
GtkTextBuffer. They are generally statically allocated on the stack 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 GtkListStore model, which is internally a simple linked
list, stores a list node in one of the pointers. The GtkTreeModelSort
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 lifecycle 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 GtkTreeStore and GtkListStore). 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
GTK_TREE_MODEL_ITERS_PERSIST flag was added to indicate this behavior.

To help show some common operation 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 callbacks.

This second example shows a quick way of iterating through a list and
getting a string and an integer from each row. The
populate_model function used below is not shown, as
it is specific to the GtkListStore. For information on how to write
such a function, see the GtkListStore documentation.

gtk_tree_path_new_from_string ()

Creates a new GtkTreePath initialized to path. path is expected to be a
colon separated list of numbers. For example, the string "10:4:0" would
create a path of depth 3 pointing to the 11th child of the root node, the 5th
child of that 11th child, and the 1st child of that 5th child. If an invalid
path string is passed in, NULL is returned.

gtk_tree_row_reference_new ()

Creates a row reference based on path. This reference will keep pointing
to the node pointed to by path, so long as it exists. It listens to all
signals emitted by model, and updates its path appropriately. If path
isn't a valid path in model, then NULL is returned.

These functions must be called exactly once per proxy when the
corresponding signal on the model is emitted. This single call
updates all row references for that proxy. Since built-in GTK+
objects like GtkTreeView already use this mechanism internally,
using them as the proxy object will produce unpredictable results.
Further more, passing the same object as model and proxy
doesn't work for reasons of internal implementation.

This type of row reference is primarily meant by structures that need to
carefully monitor exactly when a row reference updates itself, and is not
generally needed by most applications.

gtk_tree_iter_copy ()

Creates a dynamically allocated tree iterator as a copy of iter.
This function is not intended for use in applications, because you
can just copy the structs by value
(GtkTreeIter new_iter = iter;).
You must free this iter with gtk_tree_iter_free().

gtk_tree_model_iter_nth_child ()

Sets iter to be the child of parent, using the given index. The first
index is 0. If n is too big, or parent has no children, iter is set
to an invalid iterator and FALSE is returned. parent will remain a valid
node after this function has been called. As a special case, if parent is
NULL, then the nth root node is set.

gtk_tree_model_iter_parent ()

Sets iter to be the parent of child. If child is at the toplevel, and
doesn't have a parent, then iter is set to an invalid iterator and FALSE
is returned. child will remain a valid node after this function has been
called.

gtk_tree_model_ref_node ()

Lets the tree ref the node. This is an optional method for models to
implement. To be more specific, models may ignore this call as it exists
primarily for performance reasons.

This function is primarily meant as a way for views to let caching model
know when nodes are being displayed (and hence, whether or not to cache that
node.) For example, a file-system based model would not want to keep the
entire file-hierarchy in memory, just the sections that are currently being
displayed by every current view.

A model should be expected to be able to get an iter independent of its
reffed state.

gtk_tree_model_get ()

Gets the value of one or more cells in the row referenced by iter.
The variable argument list should contain integer column numbers,
each column number followed by a place to store the value being
retrieved. The list is terminated by a -1. For example, to get a
value from column 0 with type G_TYPE_STRING, you would
write: gtk_tree_model_get (model, iter, 0, &place_string_here, -1),
where place_string_here is a gchar* to be
filled with the string.
If appropriate, the returned values have to be freed or unreferenced.

gtk_tree_model_row_deleted ()

Emits the "row-deleted" signal on tree_model. This should be called by
models after a row has been removed. The location pointed to by path
should be the location that the row previously was at. It may not be a
valid location anymore.

The "row-deleted" signal

Note that no iterator is passed to the signal handler,
since the row is already deleted.

Implementations of GtkTreeModel must emit row-deleted
before removing the node from its
internal data structures. This is because models and
views which access and monitor this model might have
references on the node which need to be released in the
row-deleted handler.