another RFC for trip handling

[Dirk Hohndel]

Henrik Brautaset Aronsen <subsurface at henrik.synth.no> writes:

> Den 27.08.12 08:15, skrev Dirk Hohndel:
>> Henrik Brautaset Aronsen <subsurface at henrik.synth.no> writes:
>>>   (I still don't like automatic
>>> dive groups/trips, and this would solve that.)  But I guess I've
>>> overlooked something.  Again.
>> If you don't like them, keep them turned off and that will solve this
>> much better :-)
>
> But then I wouldn't get groups/trips at all, right?  

You didn't pull the code, it seems. Even the commit message clearly
states that having trips has nothing to do with turning on the automagic
trip generation. And realistically, the whole point of implementing this
is so that you ARE able to manually set up trips or modify the trips that
it creates automagically. That part (the manual edit) just isn't
implemented yet.

The transient trips in the current code make it extremely hard to
persistently modify them. So in order to be able to later modify tripa I
first implemented the framework that allows us to store trips and that
(at the same time) allows us to turn off this whole automagic trips
nonsense for those who don't like it (like you).

The next step will be to enable the user to explicitly prevent a certain
dive (or groups of dives) to be part of trips. And to edit trip entries. 
And to add and delete them.

The one constraint that is in the design (and not just the code) is that
trips always have to be consecutive. So you cannot have a trip and in
the middle of it is a dive that is part of a different trip or no trip
at all. And with that one (in my mind, extremely reasonable) constraint
you no longer need to manage trip numbers and try to keep them
consistent when merging different data sources, when editing trips,
adding or deleting trips, etc.

> I like groups/trips, as long as I'm in control.  Trip numbering would
> solve both use cases. If automatic trips == true, assign trip number
> when dives are imported.  But always allow manual trip assignment.

The logic behind this would get really ugly really quickly. I know. I
tried to implement it.

> What if I'm on a two-week liveboard and don't dive three days in the 
> middle?  I wouldn't get a dive trip.  What if I do different local dives 
> where I live?  I would get automatic dive trips that wouldn't make 
> sense.  I'd have to turn off and on your trip preference in regard to 
> what dives I've done lately...

I suggest that you pull the patches I have so far and look at the code
and the commit message. If after that you /still/ think that this won't
work for you, please explain in reference to the actual code and design
what's wrong - not in reference to your interpretation what my quick
announcement email might have implied about the design I have chosen.

Thanks

/D