g-object, common-lisp:standard-object, common-lisp:t

gtk-list-store, gtk-tree-model-filter, gtk-tree-model-sort, gtk-tree-store

The gtk-tree-model interface defines a generic tree interface for use by the gtk-tree-view 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 gtk-tree-view 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. "gint", "GtkButton", "gpointer", 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 gtk-tree-store and the gtk-list-store classes. 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 gtk-tree-path and the gtk-tree-iter structures. Most of the interface consists of operations on a gtk-tree-iter iterator.

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 gtk-tree-path structure 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 gtk-tree-iter iterator is a reference to a specific node on a specific model. It is a generic structure 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 the function gtk-tree-model-iter. These iterators are the primary way of accessing a model and are similar to the iterators used by the gtk-text-buffer class. 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 gtk-list-store model, which is internally a simple linked list, stores a list node in one of the pointers. The gtk-tree-model-sort class 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 does not 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 gtk-tree-store and gtk-list-store models). 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 :iters-persist flag was added to indicate this behavior.

To show some common operation of a model, some examples are provided. The first example shows three ways of getting the iterator 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.

Example: Acquiring a gtk-tree-iter iterator

;; Three ways of getting the iter pointing to the location
(let (path iter parent)
  ;; Get the iterator from a string
  (setf iter (gtk-tree-model-iter-from-string model "3:2:5"))


  ;; Get the iterator from a path
  (setf path (gtk-tree-path-new-from-string "3:2:5"))
  (setf iter (gtk-tree-model-iter model path))


  ;; Walk the tree to find the iterator
  (setf parent (gtk-tree-model-iter-nth-child model nil 3))
  (setf parent (gtk-tree-model-iter-nth-child model parent 2))
  (setf iter (gtk-tree-model-iter-nth-child model parent 5))
  ... )  

The second example shows a quick way of iterating through a list and getting a value from each row.

Example: Reading data from a gtk-tree-model

(do* ((model (gtk-tree-view-model view))             ; get the model
      (iter (gtk-tree-model-iter-first model)        ; get first iter
            (gtk-tree-model-iter-next model iter)))  ; get next iter
     ((not iter))                                    ; until iter is nil
     ;; Get a value and do something with the data
     (let ((value (gtk-tree-model-value model iter col-yearborn)))
       (gtk-list-store-set-value model iter
                                       col-yearborn
                                       (1+ value))))  

The gtk-tree-model interface contains two methods for reference counting: gtk-tree-model-ref-node and gtk-tree-model-unref-node. These two methods are optional to implement. The reference counting is meant as a way for views to let models know when nodes are being displayed. The gtk-tree-view widget will take a reference on a node when it is visible, which means the node is either in the toplevel or expanded. Being displayed does not mean that the node is currently directly visible to the user in the viewport. Based on this reference counting scheme a caching model, for example, can decide whether or not to cache a node based on the reference count. A file-system based model would not want to keep the entire file hierarchy in memory, but just the folders that are currently expanded in every current view.

When working with reference counting, the following rules must be taken into account:

• Never take a reference on a node without owning a reference on its parent. This means that all parent nodes of a referenced node must be referenced as well.
• Outstanding references on a deleted node are not released. This is not possible because the node has already been deleted by the time the row-deleted signal is received.
• Models are not obligated to emit a signal on rows of which none of its siblings are referenced. To phrase this differently, signals are only required for levels in which nodes are referenced. For the root level however, signals must be emitted at all times (however the root level is always referenced when any view is attached).

The "row-changed" signal

 lambda (model path iter)    :run-last      

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

model

The gtk-tree-model object on which the signal is emitted.

path

A gtk-tree-path instance identifying the changed row.

iter

A valid gtk-tree-iter iterator pointing to the changed row.

The "row-deleted" signal

 lambda (model path)    :run-first      

The 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.

model

The gtk-tree-model object on which the signal is emitted.

path

A gtk-tree-path instance identifying the row.

The "row-has-child-toggled" signal

 lambda (model path iter)    :run-last      

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

model

The gtk-tree-model object on which the signal is emitted.

path

A gtk-tree-path instance identifying the row.

iter

A valid gtk-tree-iter iterator pointing to the row.

The "row-inserted" signal

 lambda (model path iter)    :run-first      

The 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.

model

The gtk-tree-model object on which the signal is emitted.

path

A gtk-tree-path instance identifying the new row.

iter

A valid gtk-tree-iter iterator pointing to the new row.

The "rows-reordered" signal

 lambda (model path iter new-order)    :run-first      

The signal is emitted when the children of a node in the gtk-tree-model object have been reordered. Note that the signal is not emitted when rows are reordered by DND, since this is implemented by removing and then reinserting the row.

model

The gtk-tree-model object on which the signal is emitted.

path

A gtk-tree-path instance identifying the tree node whose children have been reordered.

iter

A valid gtk-tree-iter iterator pointing to the node whose children have been reordered.

new-order

An array of integers mapping the current position of each child to its old position before the re-ordering, i.e. new-order[newpos] = oldpos.