On Tue, Jul 22, 2014 at 3:11 PM, Dirk Hohndel <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface > > _______________________________________________ > subsurface mailing list > [email protected] > http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface _______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
