TreeModelIF

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.

interface TreeModelIF {}

Members

Functions

addOnRowChanged
void addOnRowChanged(void delegate(TreePath, TreeIter, TreeModelIF) dlg, ConnectFlags connectFlags)

This signal is emitted when a row in the model has changed.

addOnRowDeleted
void addOnRowDeleted(void delegate(TreePath, TreeModelIF) dlg, ConnectFlags connectFlags)

This signal is emitted when a row has been deleted. Note that no iterator is passed to the signal handler, since the row is already deleted. 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.

addOnRowHasChildToggled
void addOnRowHasChildToggled(void delegate(TreePath, TreeIter, TreeModelIF) dlg, ConnectFlags connectFlags)

This signal is emitted when a row has gotten the first child row or lost its last child row.

addOnRowInserted
void addOnRowInserted(void delegate(TreePath, TreeIter, TreeModelIF) dlg, ConnectFlags connectFlags)

This signal is emitted when a new row has been inserted in the model. Note that the row may still be empty at this point, since it is a common pattern to first insert an empty row, and then fill it with the desired values.

addOnRowsReordered
void addOnRowsReordered(void delegate(TreePath, TreeIter, void*, TreeModelIF) dlg, ConnectFlags connectFlags)

This signal is emitted when the children of a node in the GtkTreeModel have been reordered. Note that this signal is not emitted when rows are reordered by DND, since this is implemented by removing and then reinserting the row. See Also GtkTreeView, GtkTreeStore, GtkListStore, GtkTreeDnd, GtkTreeSortable [4] Here, iter is short for “iterator”

foreac
void foreac(GtkTreeModelForeachFunc func, void* userData)

Calls func on each node in model in a depth-first fashion. If func returns TRUE, then the tree ceases to be walked, and gtk_tree_model_foreach() returns.

getColumnType
GType getColumnType(int index)

Returns the type of the column.

getFlags
GtkTreeModelFlags getFlags()

Returns a set of flags supported by this interface. The flags are a bitwise combination of GtkTreeModelFlags. The flags supported should not change during the lifecycle of the tree_model.

getIter
int getIter(TreeIter iter, TreePath path)

Sets iter to a valid iterator pointing to path.

getIterFirst
int getIterFirst(TreeIter iter)

Initializes iter with the first iterator in the tree (the one at the path "0") and returns TRUE. Returns FALSE if the tree is empty.

getIterFromString
int getIterFromString(TreeIter iter, string pathString)

Sets iter to a valid iterator pointing to path_string, if it exists. Otherwise, iter is left invalid and FALSE is returned.

getNColumns
int getNColumns()

Returns the number of columns supported by tree_model.

getPath
TreePath getPath(TreeIter iter)

Returns a newly-created GtkTreePath referenced by iter. This path should be freed with gtk_tree_path_free().

getStringFromIter
string getStringFromIter(TreeIter iter)

Generates a string representation of the iter. This string is a ':' separated list of numbers. For example, "4:10:0:3" would be an acceptable return value for this string. Since 2.2

getStruct
void* getStruct()

the main Gtk struct as a void*

getTreeModelTStruct
GtkTreeModel* getTreeModelTStruct()
Undocumented in source.
getValist
void getValist(TreeIter iter, void* varArgs)

See gtk_tree_model_get(), this version takes a va_list for language bindings to use.

getValue
Value getValue(TreeIter iter, int column, Value value)

Initializes and sets value to that at column. When done with value, g_value_unset() needs to be called to free any allocated memory.

getValueInt
int getValueInt(TreeIter iter, int column)

Get the value of a column as a char array. this is the same calling getValue and get the int from the value object

getValueString
string getValueString(TreeIter iter, int column)

Get the value of a column as a char array. this is the same calling getValue and get the string from the value object

iterChildren
int iterChildren(TreeIter iter, TreeIter parent)

Sets iter to point to the first child of parent. If parent has no children, FALSE is returned and iter is set to be invalid. parent will remain a valid node after this function has been called. If parent is NULL returns the first node, equivalent to gtk_tree_model_get_iter_first (tree_model, iter);

iterHasChild
int iterHasChild(TreeIter iter)

Returns TRUE if iter has children, FALSE otherwise.

iterNChildren
int iterNChildren(TreeIter iter)

Returns the number of children that iter has. As a special case, if iter is NULL, then the number of toplevel nodes is returned.

iterNext
int iterNext(TreeIter iter)

Sets iter to point to the node following it at the current level. If there is no next iter, FALSE is returned and iter is set to be invalid.

iterNthChild
int iterNthChild(TreeIter iter, TreeIter parent, int n)

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.

iterParent
int iterParent(TreeIter iter, TreeIter child)

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.

onRowChangedListeners
void delegate(TreePath, TreeIter, TreeModelIF)[] onRowChangedListeners()
onRowDeletedListeners
void delegate(TreePath, TreeModelIF)[] onRowDeletedListeners()
Undocumented in source.
onRowHasChildToggledListeners
void delegate(TreePath, TreeIter, TreeModelIF)[] onRowHasChildToggledListeners()
Undocumented in source.
onRowInsertedListeners
void delegate(TreePath, TreeIter, TreeModelIF)[] onRowInsertedListeners()
Undocumented in source.
onRowsReorderedListeners
void delegate(TreePath, TreeIter, void*, TreeModelIF)[] onRowsReorderedListeners()
Undocumented in source.
refNode
void refNode(TreeIter iter)

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.

rowChanged
void rowChanged(TreePath path, TreeIter iter)

Emits the "row-changed" signal on tree_model.

rowDeleted
void rowDeleted(TreePath path)

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.

rowHasChildToggled
void rowHasChildToggled(TreePath path, TreeIter iter)

Emits the "row-has-child-toggled" signal on tree_model. This should be called by models after the child state of a node changes.

rowInserted
void rowInserted(TreePath path, TreeIter iter)

Emits the "row-inserted" signal on tree_model

rowsReordered
void rowsReordered(TreePath path, TreeIter iter, int[] newOrder)

Emits the "rows-reordered" signal on tree_model. This should be called by models when their rows have been reordered.

unrefNode
void unrefNode(TreeIter iter)

Lets the tree unref 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. For more information on what this means, see gtk_tree_model_ref_node(). Please note that nodes that are deleted are not unreffed.

Meta