dive planner update

[Dirk Hohndel]

On Thu, 2013-06-27 at 15:14 +0200, Robert Helling wrote:
> On 27.06.2013, at 15:07, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
> > On Thu, 2013-06-27 at 15:00 +0200, Robert Helling wrote:
> >> On 27.06.2013, at 14:51, Dirk Hohndel <dirk at hohndel.org> wrote:
> >> 
> > 
> > Interesting. What do others think... is that the preferred way to use
> > the planner?
> > 
> > For the tec dives I do we have a rather slow slope so going down to 60m
> > even along the fastest path will take you about 7min (unless you have a
> > scooter). So for me your algorithm not only wouldn't make things easier,
> > it would even make it impossible to plan my dives correctly (as you
> > would have me at 60m after only 2 min which will create significantly
> > more deco - and no way to change this).

> Of course, the descent velocity should be user configurable (if 10m/min suits you better use that value by all means).

I think that would make your solution much more viable.

> >> Needless to say, that does not fit all cases and having a more general
> >> descent should be possible but I would opt for the other as default.
> > 
> > How would the user switch? In an easy to understand, user friendly
> > fashion? While your way is more convenient for some I think mine is more
> > consistent for all. But if we can come up with an easy way to start with
> > yours and then being able to intuitively change to mine...
> > 
> > How about this... adding a node at say 60m / 7min inserts TWO nodes. One
> > at 60m / 2min (Robert "drop like a stone" Helling point) and the one
> > that they user actually entered. And then the first one can be manually
> > moved around and once an automatically added node like this has been
> > moved the vertical speed is no longer enforced.
> > 
> 
> Actually, that's what I wanted. My code does add two nodes to the dive plan, I should have added the second node to the graph as well.

Well - if the user can't actually move that point, then adding it
actually makes it worse...

> What about having one of the two behaviors on double clicking with a modifier key (shift say) and the other as default?

Not necessarily any more intuitive, but a possible solution.

> > Of course this creates its own set of potentially inconsistent
> > behaviors…
> 
> Indeed. One would have to figure out what is implied by moving a node around. I only to precautions not to have time travel dive plans.

Speaking of which, I am trying to fix that right now. The current code
still allows you to create dive plans that go back in time...

/D