[PATCH] Remove useless members of DiveItem
Tomaz Canabrava
tcanabrava at kde.org
Thu Apr 25 14:32:25 PDT 2013
Sorry, phone mail client is dumb.
Em 25/04/2013 17:59, "Jef Driesen" <jefdriesen at telenet.be> escreveu:
> I suppose this was intended for the list, and not me personally? :-)
>
> On 25-04-13 22:40, Tomaz Canabrava wrote:
>
>> I lost all this fun while working, shame on you guys. =)
>>
>> Linus, dont worry about Qt crashing when you delete data, everything
>> that's
>> being done behind the interface should reflect what's on the interface,
>> so, when
>> I delete the data on the fui I should also update the model. But
>> fortunately
>> this is easy to do.
>>
>> Dirk, when the models get merged or moved you just need to tell qt that
>> something moved / changed / deleted / inserted ( on the model, I don't
>> need to
>> touch interface code for that.), the interface will update when the
>> models calls
>> a callback "updated".
>>
>> Thiago, there's a working version of itemviews ng on dolphin, maybe that
>> could
>> be added to qt5. ;p
>>
>> The rest, trees in a Qt model is not the easiest part of the api, but not
>> so
>> hard after hitting the head on the wall till it bleeds.
>>
>> T
>>
>> Em 25/04/2013 15:56, "Jef Driesen" <jefdriesen at telenet.be
>> <mailto:jefdriesen at telenet.be>**> escreveu:
>>
>> 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
>> ______________________________**_________________
>> subsurface mailing list
>> subsurface at hohndel.org <mailto:subsurface at hohndel.org**>
>> http://lists.hohndel.org/cgi-**bin/mailman/listinfo/**subsurface<http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface>
>> <http://lists.hohndel.org/cgi-**bin/mailman/listinfo/**subsurface<http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface>
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130425/63a0702c/attachment.html>
More information about the subsurface
mailing list