Quick editorial comment: I am waiting for a very limited fix to the HTML/notes issue. 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
