For the impatient, here is a small tree view ‘Hello World’ program:
https://docs.gtk.org/gtk3/treeview-tutorial.html
GtkTreeModel is basically just an ‘interface’ to the data store, meaning that it is a standardised set of functions that allows a GtkTreeView widget (and the application programmer) to query certain characteristics of a data store, for example how many rows there are, which rows have children, and how many children a particular row has. It also provides functions to retrieve data from the data store, and tell the tree view what type of data is stored in the model.
Every data store must implement the GtkTreeModel interface and provide these functions, which you can use by casting a store to a tree model with GTK_TREE_MODEL(store). GtkTreeModel itself only provides a way to query a data store’s characteristics and to retrieve existing data, it does not provide a way to remove or add rows to the store or put data into the store. This is done using the specific store’s functions.
GTK comes with two built-in data stores (models): GtkListStore and GtkTreeStore. ...you should consider implementing your own custom model that stores and manipulates data your own way and implements the GtkTreeModel interface. GtkTreeStore will take care of the view side for you once you have configured the GtkTreeView to display what you want.
A model (data store) has model columns and rows. While a tree view will display each row in the model as a row in the view, the model’s columns are not to be confused with a view’s columns. A model column represents a certain data field of an item that has a fixed data type. You need to know what kind of data you want to store when you create a list store or a tree store, as you can not add new fields later on.
If you operate with tree paths, you are most likely to use a given tree path, and use functions like gtk_tree_path_up(), gtk_tree_path_down(), gtk_tree_path_next(), gtk_tree_path_prev(), gtk_tree_path_is_ancestor(), or gtk_tree_path_is_descendant().
Tree iters are used to retrieve data from the store, and to put data into the store. You get a tree iter as result if you are using gtk_tree_store_append().
Tree iters are only valid for a short time.
gtk_tree_view_set_model() connects our data store to the tree view, so it knows where to get the data to display from.
gtk_tree_view_get_model() will return the model that is currently attached to a given tree view.
/* A pointer to the model, which is only set on the root node. */
IdeTreeModel *model;
/* The following are fields containing the values for various properties on the tree node.
* Usually, icon, display_name, and item will be set on all nodes. */
GIcon *icon;
GIcon *expanded_icon;
gchar *display_name;
GObject *item;
gchar *tag;
GList *emblems;
/* The following items are used to maintain a tree structure of nodes for which we can use O(1) operations.
* The link is inserted into the parents children queue. The parent pointer is unowned, and set by the parent (cleared upon removal).
* This also allows maintaining the tree structure with zero additional allocations beyond the nodes themselves.
*/
IdeTreeNode *parent;
GQueue children;
GList link;
/* Foreground and Background colors */
GdkRGBA background;
GdkRGBA foreground;
/* Flags for state cell renderer */
IdeTreeNodeFlags flags;
/* When did we start loading? This is used to avoid drawing "Loading..." when the tree loads really quickly. Otherwise, we risk looking janky when the loads are quite fast. */
gint64 started_loading_at;
/* If we're currently loading */
guint is_loading : 1;
/* If the node is a header (bold, etc) */
guint is_header : 1;
/* If this is a synthesized empty node */
guint is_empty : 1;
/* If there are errors associated with the node's item */
guint has_error : 1;
/* If the node maybe has children */
guint children_possible : 1;
/* If this node needs to have the children built */
guint needs_build_children : 1;
/* If true, we remove all children on collapse */
guint reset_on_collapse : 1;
/* If pango markup should be used */
guint use_markup : 1;
/* If true, we use ide_clear_and_destroy_object() */
guint destroy_item : 1;
/* If colors are set */
guint background_set : 1;
guint foreground_set : 1;
};
src/libide/tree/ide-tree-node.c (1763) /* If the node is not on screen, we need to animate until we get there. */
src/libide/tree/ide-tree-node.c (1776) /* FIXME: Time period comes from gtk animation duration. Not curently available in pubic API.
* We need to be greater than the max timeout it could take to move, since we must have it on screen by then.
* One alternative might be to check the result and if we are still not on screen, then just pin it to a row-height from the top or bottom.
* This function is called when a node has been activated in the tree and allows for the addin to perform any necessary operations in response to that.
* If the addin performs an action based on the activation request, then it should return %TRUE from this function so that no further addins may respond to the action.
* Returns: %TRUE if the activation was handled, otherwise %FALSE
HACK: @width is the min_width returned in our get_preferred_width() function. That results in pretty bad values here, so we will do this by assuming we are the only widget in the tree view.
* This makes this cell very much not usable for generic situations, but it does make it so we can do text wrapping without resorting to GtkListBox *for our exact usecase only*.
* The problem here is that we require the widget to already be realized and allocated and that we are the only renderer within the only column (and also, in a treeview) without exotic styling.
* If we get something absurdly small (like 50) that is because we are hitting our minimum size of (xpad * 2).
* So this works around the issue and tries to get something reasonable with wrapping at the 200px mark (our ~default width for panels).
* Furthermore, we need to queue a resize when the column size changes (as it will from resizing the widget). So the tree view must also call gtk_tree_view_column_queue_resize().
