Re: [gtkmm] Custom tree model

[Christer Palm <palm nogui se>]

Aaron Isotton wrote:
> As far as I can see, this means that a GtkTreeIter will be valid until
> the model is unchanged and doesn't emit a signal;

Hmmmm... No. But I guess you intended to write something else(?)

>  the problem is that
> everytime get_iter_vfunc is called I have to allocate a new iterator and
> put a pointer to it into user_data because my iterators cannot be easily
> converted to three void pointers;

Yes

> but when do I free the data allocated there?

You'd have to track the "back-end" iterators you allocate, and free them 
at the appropriate time. Following the documented logic, I guess that 
would be whenever you emit a changed signal on the model, in which case 
the view would stop using all outstanding iterators and get new ones.

I can recommend that you start out by writing a simple model that prints 
out every call to your implementation. You will see that the view 
(standard TreeView, that is) interaction with the model follows some 
rather simple patterns as you do different things to the view.

If you want, I can send you code for the model I wrote to explore this. 
It's in a rather experimental state at the moment, but you should be 
able to use it as a boilerplate.

>  Or do I _have_ to use only the three pointers and no additional
> data?

The GtkTreeIter is a black box with no meaning outside the model to 
which it belongs, so you can use the three pointers it defines for 
anything, including extending the iterator itself with a pointer to 
off-board data.

> Ah.  Nice to know.

To give you the details, the problem is the timing of your model 
changes. It appears that you cannot just emit "changed" signals at any 
time. If the view is in the middle of a flow, it won't pick up your 
signals until the flow has been completed. Basically this means that you 
can't emit signals from within the model interface implementation - the 
underlying model has to be "frozen" while the view is updating.

--
Christer Palm