Re: [gtkmm] Custom tree model

[Christer Palm <palm nogui se>]

Aaron Isotton wrote:
> - The GtkTreeIter structure is okay for C programs, but in my case I
> have a custom iterator class which can not be converted to three void*
> pointers in a nice way.  What I'd like to do is to allocate a iterator
> for every GtkTreeIter and put a pointer to it into user_data.  The
> problem is that I don't know when to free the allocated object, to avoid
> memory leaks.  Any ideas?

This, in fact, _is_ documented :-)

From the TreeModel docs:

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 Gtk::TreeStore and Gtk::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 
GTK_TREE_MODEL_ITERS_PERSIST flag was added to indicate this behavior.


Beware though - this is in theory. I tried to do something similar to 
what you are doing, and frankly, I had to give up. The TreeView is not 
particularly happy with the model changing outside its control. I've 
seen all sorts of behaviour, including using invalidated (as per the 
documentation) iterators, and various internal asserts complaining about 
 that the model has changed, even though these changes have been 
properly communicated to the view.

I ended up solving my problem the "wrong" way around - i.e. using a 
stock model and have the controller synchronize the TreeView model with 
the actual application model.

This appears to be the obviuous way for many people to solve this kind 
of problem, which is funny because in the Model-View-Controller 
paradigm, the model does _not_ talk to the controller!

--
Christer Palm