ListStore


Object Hierarchy:

Gtk.ListStore Gtk.ListStore Gtk.ListStore GLib.Object GLib.Object GLib.Object->Gtk.ListStore Gtk.Buildable Gtk.Buildable Gtk.Buildable->Gtk.ListStore Gtk.TreeDragDest Gtk.TreeDragDest Gtk.TreeDragDest->Gtk.ListStore Gtk.TreeDragSource Gtk.TreeDragSource Gtk.TreeDragSource->Gtk.ListStore Gtk.TreeModel Gtk.TreeModel Gtk.TreeModel->Gtk.ListStore Gtk.TreeSortable Gtk.TreeSortable Gtk.TreeSortable->Gtk.ListStore

Description:

[ CCode ( type_id = "gtk_list_store_get_type ()" ) ]
public class ListStore : Object, Buildable, TreeDragDest, TreeDragSource, TreeModel, TreeSortable

The ListStore object is a list model for use with a TreeView widget.

It implements the TreeModel interface, and consequentialy, can use all of the methods available there. It also implements the TreeSortable interface so it can be sorted by the view. Finally, it also implements the tree drag and drop interfaces.

The ListStore can accept most GObject types as a column type, though it can’t accept all custom types. Internally, it will keep a copy of data passed in (such as a string or a boxed pointer). Columns that accept Object s are handled a little differently. The ListStore will keep a reference to the object instead of copying the value. As a result, if the object is modified, it is up to the application writer to call row_changed to emit the row_changed signal. This most commonly affects lists with Pixbufs stored.

An example for creating a simple list store:

enum {
COLUMN_STRING,
COLUMN_INT,
COLUMN_BOOLEAN,
N_COLUMNS
};

{
GtkListStore *list_store;
GtkTreePath *path;
GtkTreeIter iter;
gint i;

list_store = gtk_list_store_new (N_COLUMNS,
G_TYPE_STRING,
G_TYPE_INT,
G_TYPE_BOOLEAN);

for (i = 0; i < 10; i++)
{
gchar *some_data;

some_data = get_some_data (i);

// Add a new row to the model
gtk_list_store_append (list_store, &iter);
gtk_list_store_set (list_store, &iter,
COLUMN_STRING, some_data,
COLUMN_INT, i,
COLUMN_BOOLEAN, FALSE,
-1);

// As the store will keep a copy of the string internally,
// we free some_data.
g_free (some_data);
}

// Modify a particular row
path = gtk_tree_path_new_from_string ("4");
gtk_tree_model_get_iter (GTK_TREE_MODEL (list_store),
&iter,
path);
gtk_tree_path_free (path);
gtk_list_store_set (list_store, &iter,
COLUMN_BOOLEAN, TRUE,
-1);
}

Performance Considerations

Internally, the ListStore was implemented with a linked list with a tail pointer prior to GTK+ 2.6. As a result, it was fast at data insertion and deletion, and not fast at random data access. The ListStore sets the ITERS_PERSIST flag, which means that TreeIters can be cached while the row exists. Thus, if access to a particular row is needed often and your code is expected to run on older versions of GTK+, it is worth keeping the iter around.

Atomic Operations

It is important to note that only the methods insert_with_values and insert_with_valuesv are atomic, in the sense that the row is being appended to the store and the values filled in in a single operation with regard to TreeModel signaling. In contrast, using e.g. append and then @set will first create a row, which triggers the row_inserted signal on ListStore. The row, however, is still empty, and any signal handler connecting to row_inserted on this particular store should be prepared for the situation that the row might be empty. This is especially important if you are wrapping the ListStore inside a TreeModelFilter and are using a TreeModelFilterVisibleFunc. Using any of the non-atomic operations to append rows to the ListStore will cause the TreeModelFilterVisibleFunc to be visited with an empty row first; the function must be prepared for that.

GtkListStore as GtkBuildable

The GtkListStore implementation of the GtkBuildable interface allows to specify the model columns with a `<columns>` element that may contain multiple `<column>` elements, each specifying one model column. The “type” attribute specifies the data type for the column.

Additionally, it is possible to specify content for the list store in the UI definition, with the `<data>` element. It can contain multiple `<row>` elements, each specifying to content for one row of the list model. Inside a `<row>`, the `<col>` elements specify the content for individual cells.

Note that it is probably more common to define your models in the code, and one might consider it a layering violation to specify the content of a list store in a UI definition, data, not presentation, and common wisdom is to separate the two, as far as possible.

An example of a UI Definition fragment for a list store:

<object class="GtkListStore">
<columns>
<column type="gchararray"/>
<column type="gchararray"/>
<column type="gint"/>
</columns>
<data>
<row>
<col id="0">John</col>
<col id="1">Doe</col>
<col id="2">25</col>
</row>
<row>
<col id="0">Johan</col>
<col id="1">Dahlin</col>
<col id="2">50</col>
</row>
</data>
</object>

Namespace: Gtk
Package: gtk+-3.0

Content:

Creation methods:

Methods:

Inherited Members:

All known members inherited from class GLib.Object
All known members inherited from interface Gtk.TreeDragDest
All known members inherited from interface Gtk.TreeDragSource



2022 vala-language.org