[PATCH 2/2] tree_selected_foreach: ingore trips in the selection

[Dirk Hohndel]

Ok, here is a quick and dirty, virtually untested patch that does a linear time walk of the dive table and should do everything we need with the exception of maintaining the expanded state of the trips (easy enough to add).

Please give it a look and let me know what you think.

/D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: delete_multiple.diff
Type: application/octet-stream
Size: 2328 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20120927/10ab9f78/attachment.obj>
-------------- next part --------------

On Sep 27, 2012, at 5:12 PM, Lubomir I. Ivanov wrote:

> On 28 September 2012 02:46, Dirk Hohndel <dirk at hohndel.org> wrote:
>>> yeah i know,
>>> some of that is already in master. of course we can revert it if
>>> better solutions are viable…
>> 
>> I would really prefer a different solution. Convenient as the tree model is for
>> some things, here it seems to make much more sense to track things in the dives.
>> We will recreate the model, anyway.
>> All we need to do is make sure that the time stamps are adjusted.
>> Why can't we leave the tree model untouched, use it to update the time stamps
>> and to get rid of the dive_trip entries in the dive_trip_list. And then discard the
>> whole model and recreate it.
>> The more I think about it, that seems the way to go.
>> Does this make sense to you?
>> 
> 
> i think so. a good construct, i think, would be not to even depend at
> all on the model to update the trip times
> i.e. a design where the tree is used only for user interaction (+
> visual) and the dive / trip structs actually dictate everything.
> 
>>> not sure it would work though? the two problems i've encountered were:
>>> 1) we should gtk_tree_selection_selected_foreach() instead of other
>>> methods, but should not modify the tree from it.
>> 
>> Correct. Don't modify it. We're throwing it away afterwards, anyway.
>> 
>>> 2) update_trip_timestamp() is the fastest way to modify the trip date
>>> based on remaining dives if needed, but it actually requires an
>>> updated tree.
>> 
>> It really doesn't. You can mark the dives as deleted and simply walk the
>> children of the trip in the tree to find the first and last child that are not deleted.
>> Still O(n) algorithm.
>> 
> 
> most of the troubles came from me not using update_trip_timestamp()
> correctly, i guess.
> however, i do think there has to be a better way to know which dives
> are in a trip (first, last) without even checking the gtk tree.
> the design that is in my head (sort of) is even to store tree paths in
> the structs at all times, if possible which will potentially avoid the
> get_path_from_xx iterations and such.
> 
>>> the combination of the above led me to allocated the array.
>>> 
>>> there are possibly much better solutions...i.e. like you mention
>>> above, the list is repopulated anyway, so why not use dive, trip
>>> struct specific flags.
>>> divelist.c is getting quite entangled, i think.
>> 
>> It is. Tell me about it.
>> 
>> If this is getting too wild for you let me know and I'll take a stab at it.
>> 
> 
> i can look at it more tomorrow, but the problem on my end is lack of
> complete understanding and experience with divelist.c (and gtk trees
> in that aspect).
> so considering the 2.0 release plan, its perhaps its better if you
> took this over...
> 
>>>> And re-allocating the array on each addition is evil anyway. Ugh, what
>>>> horrible O(n**2) behavior, although some allocators may avoid some of
>>>> it thanks to extra slack.
>>>> 
>>> 
>>> i proposed allocating in chunks of say 128 GtkTreeIter values if that
>>> is better sound,
>>> however the root of the method is essentially a gtk api "workaround".
>>> outdated gtk versions, does not even provide a simple method to
>>> retrieve the selection length. :\
>> 
>> I would like to abandon that direction and go towards what I suggested above.
>> 
> 
> yep, i agree.
> a bit tired since its quite late, so i may be talking nonsense, sorry
> about that if so.
> 
> lubomir
> --