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

[Lubomir I. Ivanov]

On 28 September 2012 08:17, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> 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.
>

one thing i've noticed, the iterator needs to move back when we shift
the dive list within the main loop in delete_selected_dives(), so that
selected dives are not skipped (i--).
this patch (attachment) add the above to yours and also replaces the
delete_single_dive() with the new one, that can also be reused in
delete_dive_cb().

however delete_dive_cb() also needs to update the parent trip ("when"
flag) and the expanded states.
i wonder if delete_dive_cb() and delete_selected_dives_cb() should
only delete the dives (via delete_singe_dive()) and store a per
dive_trip "needs_update" flag, for the trip from which dives were
deleted.

delete_selected_dives() still has to iterate trough the entire list to
collect the selected dives unless we have the selected dives pointers
allocated in a dynamic buffer, which can be controlled via
gtk_tree_selection_set_select_function().

dive_list_update_dives() calls fill_dives() which also iterates trough
the entire list again, so perhaps it should take care of which dives
were previously selected, which trips have to be expanded and updated
before the model is recreated.

----

another thing which i would have definitely have done is to have a
better dive<->trip control, by having a "int total_dives" and "struct
dive **divelist" members of struct dive_trip, where "divelist" is a
dynamic buffer storing pointers to all dives children of the said trip
(or alternatively storing their indexes - int *diveindexes, given that
the divelist is a public variable). then when a trip "needs_update" it
is only required to iterate trough these children and grab the
smallest "when" flag. perhaps, later on not only the "when" flag has
to be updated, but also other properties of a trip
(cough...images...:))

excluding the potential downsides of how reliable a mem. mapper is for
small chunks, i was recently working on something that pretty much
forced me to do some of the explained above, because:
1) the application API was not convenient without it in regard of
child<->parent object communication.
2) i had to iterate trough many values to get a single object flag

lubomir
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: delete_multiple2.diff
Type: application/octet-stream
Size: 5649 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20120928/fb3c9fdf/attachment-0001.obj>