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

[Lubomir I. Ivanov]

On 28 September 2012 18:53, Dirk Hohndel <dirk at hohndel.org> wrote:
> "Lubomir I. Ivanov" <neolit123 at gmail.com> writes:
>> 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.
>
> Well, since they KNOW which trip they are in and can easily detect if
> they are the relevant dive in the trip (by being the one where the
> timestamps match), this is easy, too, right?
>

i was thinking more towards moving these flag checks in fill_dives(),
but you've mentioned that you don't wan't to clutter it any more.
the dive no longer exists once deleted so a flag has to remain in the
trip and perhaps should be cleared after the check.
i may also be missing obvious things.

>> 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().
>
> But think about it. Iterating once through the entire list is blazing
> fast. It's an array with at worst a few thousand entries. That takes no
> time at all compared to all the crud and overhead of traversing the Gtk
> model.
>

gtk is also dynamically linked and the functions in there call other
functions, so much slower.
on the other hand, straight forward iteration trough local data
structures - quite fast indeed.

>> 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.
>
> I am loath to make the fill_dive function even more complex. It's bad
> enough as it is. Again, as long as you are talking about walking the
> array this is really low overhead.
>
>> ----
>>
>> 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...:))
>
> I know, people want that. But I disagree with your statement that we
> need a data structure to hold the children. That's just something we
> need to maintain - and we have all the information that we need.
>
> The dive_table is chronologically ordered. So if you have a dive_trip
> find the dive that matches it's timestamp and keep walking forward in
> the list until you either have a dive that is not in a trip or you have
> a dive with a timestamp matching the next trip. All this is O(n) and
> given how small n is that means it's very simple.
>
> The overhead (and risk of errors) in maintaining a complicated
> structure... no way.
>

i'm always tempted towards that for a perhaps cleaner api, but i agree
- there are some risks...

> And as to storing other 'assets'. I'd do that per dive and simply have
> everything else in a database (who knows what people will end up wanting
> to store) and then store a unique key into that database in the dive or
> the dive trip (depending what you want to associate those assets with).
>

this is true considering that the chronological order is keeping
everything together. for a more unsorted type of list where there are
just some general groups of objects, there is no other way to link
parent<->children objects without some sort of pointers and markers.
so as long as the chronological order is kept in the core of the
design of trips and dives, extra assets should easily work.

i must admit that i may have designed that a bit differently and
probably instead use a more general dive "groups" that are not
strongly related of the properties of the dives inside. i'm not very
understanding of both the practice and theory of geared diving, but i
always had this picture of my head of some marine biologists living in
a bamboo sheds next to a lagoon, diving every day and wanting to add
all their turtle photos and dives into groups. this would work with
trips as well i guess... :-)

lubomir
--