dive planner update
tcanabrava at kde.org
Thu Jun 27 06:27:02 PDT 2013
On Thu, Jun 27, 2013 at 10:14 AM, Robert Helling <helling at atdotde.de> 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).
>>> 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.
> What about having one of the two behaviors on double clicking with a modifier key (shift say) and the other as default?
>> Of course this creates its own set of potentially inconsistent
> 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.
I think that time travels are already forbidden - if not, that's a bug
on my code. :)
One thing that could happen to help the poor user is to calculate -
but not plot - the deco on every mouseMove, and use the final ascent
time as an tooltip telling the user how much longer the dive will be
if he dropped the handler at that specific point.
> Robert C. Helling Elite Master Course Theoretical and Mathematical Physics
> Scientific Coordinator
> Ludwig Maximilians Universitaet Muenchen, Dept. Physik
> print "Just another Phone: +49 89 2180-4523 Theresienstr. 39, rm. B339
> stupid .sig\n"; http://www.atdotde.de
> subsurface mailing list
> subsurface at hohndel.org
More information about the subsurface