[PATCH] Remove useless members of DiveItem

Jef Driesen jefdriesen at telenet.be
Thu Apr 25 11:55:54 PDT 2013


On 25-04-13 17:30, Dirk Hohndel wrote:
> On Thu, 2013-04-25 at 08:25 -0700, Linus Torvalds wrote:
>> I think you can do similar things in GtkTreeView by
>> specifying your own renderer for each column. I don't *think* you
>> necessarily have to have a 1:1 relationship between treeview columns
>> and tree models. So *maybe* we could have made the tree model just
>> contain the pointer to the dive (or the dive index), and not had all
>> those individual fields there, and then just built up the tree view
>> columns and have a renderer that looked up the data for each of them.
>>
>> So the reason we did it like we did in the gtk version was that all
>> the cell renderer and treeview stuff is %$#! confusing, and I started
>> out without specialty renderers. I'm not sure it's the only way to do
>> it, though.
>
> IIRC the sorting doesn't work unless you have the values in the model -
> but maybe that could have been fixed with additional custom sort
> functions.

Yes, Gtk supports custom sort functions. So you can store a pointer in the data 
model, and render or sort as you like. Requires a little bit more code than just 
sorting on a column of course.

> Still doesn't change the fun that you can't make any changes to the
> model w/o causing all kinds of nightmares (iters become invalid and fun
> sideeffects like this).

I think you can change the data in the model, as long as you notify the model of 
the change. How else would it know about the change, if you store just a pointer 
in the model? If you store the actual data in the model, and change through the 
gtk functions, then the view should update automatically.

The fact that iterators are invalidated after certain operations (removal of 
nodes, etc) is not unexpected I think. Depends on the underlying container 
whether this is possible. This is true in C++ too. Removing an element from a 
STL vector invalidates all iterators.

> Well, maybe we'll run into the same crap with Qt at some point. Let's
> wait and see.

:-)

(I wish I could have helped you a bit more with the gtk stuff, but as you know 
I'm already pretty busy with libdivecomputer alone :-)).

Jef


More information about the subsurface mailing list