Struct gtk4::TreeModel [−][src]
pub struct TreeModel(_);
Expand description
The tree interface used by GtkTreeView
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 data structure. The
programmer just has to implement this interface on their own data
type 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 (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 TreeStore
and the 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 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. A TreePath
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 TreeIter
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
TreeModelExt::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
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 ListStore
model, which is internally a simple
linked list, stores a list node in one of the pointers. The
TreeModel
Sort 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 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 TreeModelFlags::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.
Acquiring a TreeIter
⚠️ The following code is in c ⚠️
// Three ways of getting the iter pointing to the location
GtkTreePath *path;
GtkTreeIter iter;
GtkTreeIter parent_iter;
// get the iterator from a string
gtk_tree_model_get_iter_from_string (model,
&iter,
"3:2:5");
// get the iterator from a path
path = gtk_tree_path_new_from_string ("3:2:5");
gtk_tree_model_get_iter (model, &iter, path);
gtk_tree_path_free (path);
// walk the tree to find the iterator
gtk_tree_model_iter_nth_child (model, &iter,
NULL, 3);
parent_iter = iter;
gtk_tree_model_iter_nth_child (model, &iter,
&parent_iter, 2);
parent_iter = iter;
gtk_tree_model_iter_nth_child (model, &iter,
&parent_iter, 5);
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 ListStore
. For information on
how to write such a function, see the ListStore
documentation.
Reading data from a TreeModel
⚠️ The following code is in c ⚠️
enum
{
STRING_COLUMN,
INT_COLUMN,
N_COLUMNS
};
...
GtkTreeModel *list_store;
GtkTreeIter iter;
gboolean valid;
int row_count = 0;
// make a new list_store
list_store = gtk_list_store_new (N_COLUMNS,
G_TYPE_STRING,
G_TYPE_INT);
// Fill the list store with data
populate_model (list_store);
// Get the first iter in the list, check it is valid and walk
// through the list, reading each row.
valid = gtk_tree_model_get_iter_first (list_store,
&iter);
while (valid)
{
char *str_data;
int int_data;
// Make sure you terminate calls to gtk_tree_model_get() with a “-1” value
gtk_tree_model_get (list_store, &iter,
STRING_COLUMN, &str_data,
INT_COLUMN, &int_data,
-1);
// Do something with the data
g_print ("Row %d: (%s,%d)\n",
row_count, str_data, int_data);
g_free (str_data);
valid = gtk_tree_model_iter_next (list_store,
&iter);
row_count++;
}
The TreeModel
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. TreeView
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).
Implements
Trait Implementations
This method returns an ordering between self
and other
values if one exists. Read more
This method tests less than (for self
and other
) and is used by the <
operator. Read more
This method tests less than or equal to (for self
and other
) and is used by the <=
operator. Read more
This method tests greater than (for self
and other
) and is used by the >
operator. Read more
Returns the type identifier of Self
.
Auto Trait Implementations
impl RefUnwindSafe for TreeModel
impl UnwindSafe for TreeModel
Blanket Implementations
Mutably borrows from an owned value. Read more
Upcasts an object to a superclass or interface T
. Read more
Upcasts an object to a reference of its superclass or interface T
. Read more
Tries to downcast to a subclass or interface implementor T
. Read more
Tries to downcast to a reference of its subclass or interface implementor T
. Read more
Tries to cast to an object of type T
. This handles upcasting, downcasting
and casting between interface and interface implementors. All checks are performed at
runtime, while downcast
and upcast
will do many checks at compile-time already. Read more
Tries to cast to reference to an object of type T
. This handles upcasting, downcasting
and casting between interface and interface implementors. All checks are performed at
runtime, while downcast
and upcast
will do many checks at compile-time already. Read more
Casts to T
unconditionally. Read more
Casts to &T
unconditionally. Read more
Returns true
if the object is an instance of (can be cast to) T
.
pub fn set_property<'a, N, V>(
&self,
property_name: N,
value: V
) -> Result<(), BoolError> where
N: Into<&'a str>,
V: ToValue,
pub fn set_property_from_value<'a, N>(
&self,
property_name: N,
value: &Value
) -> Result<(), BoolError> where
N: Into<&'a str>,
pub fn set_properties_from_value(
&self,
property_values: &[(&str, Value)]
) -> Result<(), BoolError>
pub fn has_property<'a, N>(&self, property_name: N, type_: Option<Type>) -> bool where
N: Into<&'a str>,
pub fn find_property<'a, N>(&self, property_name: N) -> Option<ParamSpec> where
N: Into<&'a str>,
Safety Read more
Safety Read more
Safety Read more
Safety Read more
pub fn connect<'a, N, F>(
&self,
signal_name: N,
after: bool,
callback: F
) -> Result<SignalHandlerId, BoolError> where
N: Into<&'a str>,
F: 'static + Fn(&[Value]) -> Option<Value> + Send + Sync,
Same as connect
but takes a SignalId
instead of a signal name.
pub fn connect_local<'a, N, F>(
&self,
signal_name: N,
after: bool,
callback: F
) -> Result<SignalHandlerId, BoolError> where
N: Into<&'a str>,
F: 'static + Fn(&[Value]) -> Option<Value>,
Same as connect_local
but takes a SignalId
instead of a signal name.
pub unsafe fn connect_unsafe<'a, N, F>(
&self,
signal_name: N,
after: bool,
callback: F
) -> Result<SignalHandlerId, BoolError> where
N: Into<&'a str>,
F: Fn(&[Value]) -> Option<Value>,
Same as connect_unsafe
but takes a SignalId
instead of a signal name.
Emit signal by signal id.
Same as emit
but takes Value
for the arguments.
Emit signal by its name.
Same as emit_by_name
but takes Value
for the arguments.
Emit signal with details by signal id.
Same as emit_with_details
but takes Value
for the arguments.
pub fn connect_notify<F>(&self, name: Option<&str>, f: F) -> SignalHandlerId where
F: 'static + Fn(&T, &ParamSpec) + Send + Sync,
pub fn connect_notify_local<F>(
&self,
name: Option<&str>,
f: F
) -> SignalHandlerId where
F: 'static + Fn(&T, &ParamSpec),
pub unsafe fn connect_notify_unsafe<F>(
&self,
name: Option<&str>,
f: F
) -> SignalHandlerId where
F: Fn(&T, &ParamSpec),
pub fn bind_property<'a, O, N, M>(
&'a self,
source_property: N,
target: &'a O,
target_property: M
) -> BindingBuilder<'a> where
O: ObjectType,
N: Into<&'a str>,
M: Into<&'a str>,
Returns a SendValue
clone of self
.