Re: [gtkmm] Understanding Gtk::TreeView

[Matthew Walton <mxw00u Cs Nott AC UK>]

On Fri, 2002-09-20 at 20:38, James T. Richardson, Jr. wrote:
> Hello, I was wondering if someone could verify my understanding of the Gtk::TreeView (and related) classes. I come from Windows programming background and implementing the Gtk::TreeView seems to be overly-complex.

Yes, it's complicated, but it is extremely flexible.

> /*
> 	This class represents a vertical column of data
> 	each branch of the tree can have data (i.e. string) 
> 	in each column. this class tracks all of those columns.
> 	Is this a linked list???
> */
> 
> class MyTreeViewColumns : public Gtk::TreeModel::ColumnRecord
> {
> public:
> 	MyTreeViewCoumns() { add(m_col_text); }	// when we create a new 
> 	Gtk::TreeModelColumn<Glib::ustring>	m_col_text;	// this is the "name" of the column??
> };

I always think of this as like a structure for the data model, telling
it what columns it should have, what to call them and what data types
they will contain.

> class MyTreeView : public Gtk::ScrolledWindow
> {
> public:
> 	MyTreeView();
> 	~MyTreeView();
> 
> 	MyTreeViewColumns	m_Columns;
> 
> protected:
> 	Glib::RefPtr<Gtk::ListStore>	m_refListStore;
> 	Gtk::TreeView			m_TreeView
> 
> 	// m_refListStore is a smart-pointer to a linked list of items
> 	// 	that are 'in' the tree. One thing i'm not sure of is 
> 	// 	how the list is sorted. what about items that have 
> 	//	children that have children?

ListStore sorting is very simple, as items in a ListStore can't have
children. That's for TreeStores, and as far as I'm aware, TreeStore
sorting doesn't actually work at the moment. Didn't last time I looked
anyway, I hope someone can tell me different. Don't know if this is a
GTK+ or gtkmm thing though.

> 	//
> 	// m_TreeView is the class that handles the display of the TreeView,
> 	// 	emits signals for events (expanded, collapsed) for the treeview.
> };

Yup. It knows squat about the underlying data and can't affect it either
(except through specific editing operations in editable cells). This is
a Good Thing.

> 	m_refListStore = Gtk::ListStore::create(m_Columns);	// create the list store,
> 								// the list store is where we store all of the 'stuff'
> 								// to be displayed? for each column?

The ListStore stores all the data to be displayed. Each item has a
number of columns, which may or may not contain data depending on if
they've been populated or not. That, of course, is up to the programmer.

> 	m_TreeView.set_model(m_refListStore);			// tell the treeview to use the data in the m_refListStore
> 
> 	// add some test branches to the tree
> 	for(int i = 0; i < 10; ++i)
> 	{
> 		Gtk::TreeModel::Row row = *(m_refListStore->append());	// create a new item (branch? leaf?) in the tree

As it's a ListStore, this is an item in the list. For a TreeStore,
things are slightly different of course, as it stores data in a tree.

> 		const Glib::ScopedPtr<char> text_buf(g_strdup_printf("message #%d", i)); // const Glib::ScopedPtr<char> looks like a fancy c-style string, is it?

I have no idea what that bit of code is for. Seems like a long way
around... and who sneaked Glib::ScopedPtr<> into the API without me
noticing?

> 		row[m_Columns.m_col_text] = text_buf.get();	// I'm confused here by row[m_Columns.m_col_text].... are we using as an index of the array of available columns?

Basically, Row::operator[] accesses columns within the row, and the
indexing is accomplished using the TreeModelColumnRecord class you made
earlier.

> 	m_TreeView.append_column("Messages", m_Columns.m_col_text); // i'm pretty sure this just adds the column to the treeview (hasta have at least 1 column, right?) 
> 								   // but i need to look at the documentation for append_column before i know what's going on.

It does, but it also does some behind-the-scenes work that tells the
TreeView how to display what's in the column. This is good for simple
stuff like displaying columns with text in, but TreeView is capable of
far more complex behaviour, such as modifying how some columns are
displayed based on the contents of other columns - which may not appear
in the UI at all.


Hope that was vaguely coherent. Might not be 100% accurate, but that's
my understanding of it.