[RFC PATCH] Add 'create new trip' option for downloading dives from the dive computer

[Tomaz Canabrava]

On Tue, Jul 22, 2014 at 3:11 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> Quick editorial comment:
>
> I am waiting for a very limited fix to the HTML/notes issue.

I send that a few moments ago. =p

> Everything else I will look at one by one and only take things that are an
> obvious improvement with no UI / documentation impact.
> Beta 3 this week once I have more time (my guess is tomorrow or Thursday),
> and a 4.2 release hopefully soon thereafter.
>
> THEN I'll look into things like this :-)
>
> /D
>
> On Tue, Jul 22, 2014 at 11:05:53AM -0700, Linus Torvalds wrote:
>> On Tue, Jul 22, 2014 at 1:00 AM, Martin Gysel <me at bearsh.org> wrote:
>> >
>> > I like the idea but why not disable the merging unconditionally in that
>> > case. I think it's not really intuitive the have an option to create a
>> > new trip but still allow merging with older dives.
>>
>> Agreed, it would probably be a good idea to limit merging.
>>
>> In fact, our old rule of "we can merge dives that are not in a trip
>> with dives that are in a trip" is probably bogus to begin with, but
>> the reason we have it is that we actually *do* want to generally merge
>> newly downloaded dives into existing trips.
>>
>> So the fix is probably to say "don't merge dives if they have
>> different trip information, *except* for the special case of a newly
>> downloaded dive that has no trip data".
>>
>> Something like the attached patch.
>>
>> > another option or way to do it would be the create a staging area which
>> > basically is a special trip which is visible if dives are in it
>> > otherwise not. from this area the user can edit, move, merge with others
>> > or delete the dives.
>>
>> Well, that is basically what that new trip is, except it doesn't
>> introduce any new artificial grouping, just uses our existing
>> infrastructure.
>>
>>              Linus
>
>>  dive.c | 18 +++++++++++++++---
>>  1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/dive.c b/dive.c
>> index acab8ff52b19..856b9c3661de 100644
>> --- a/dive.c
>> +++ b/dive.c
>> @@ -1829,6 +1829,11 @@ static int match_dc_dive(struct divecomputer *a, struct divecomputer *b)
>>       return 0;
>>  }
>>
>> +static bool new_without_trip(struct dive *a)
>> +{
>> +     return a->downloaded && !a->divetrip;
>> +}
>> +
>>  /*
>>   * Do we want to automatically try to merge two dives that
>>   * look like they are the same dive?
>> @@ -1862,9 +1867,16 @@ static int likely_same_dive(struct dive *a, struct dive *b)
>>  {
>>       int match, fuzz = 20 * 60;
>>
>> -     /* Don't try to merge dives in different trips */
>> -     if (a->divetrip && b->divetrip && a->divetrip != b->divetrip)
>> -             return 0;
>> +     /* Don't try to merge dives with different trip information */
>> +     if (a->divetrip != b->divetrip) {
>> +             /*
>> +              * Exception: if the dive is downloaded without any
>> +              * explicit trip information, we do want to merge it
>> +              * with existing old dives even if they have trips.
>> +              */
>> +             if (!new_without_trip(a) && !new_without_trip(b))
>> +                     return 0;
>> +     }
>>
>>       /*
>>        * Do some basic sanity testing of the values we
>
>> _______________________________________________
>> subsurface mailing list
>> subsurface at hohndel.org
>> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface