Small issue when entering a dive plan

[Dirk Hohndel]

On Fri, May 30, 2014 at 11:04:15AM +0200, Robert Helling wrote:
> > On Thu, May 29, 2014 at 04:35:18PM -0700, Dirk Hohndel wrote:
> >> I haven't spent any time looking into this, but I noticed that I cannot
> >> change the duration of any segment of a dive plan in the data table. You
> >> can change the depth, but not the duration.
> > 
> > Interesting - Tomaz pointed out that this was intentionally implemented as
> > such by Robert.
> > 
> > I wonder why...
> 
> because I was lazy.

Excellent reason. I could point at a number of "design decisions" in
Subsurface that stem from that source...

> And thinking more about it, my intention was based on a wrong assumption.
> I wanted to avoid dealing with points that change their order by typing
> in the time field. So I though I let only the runtime be endurable, (so
> only absolute times in the old sense) not the duration. But this does’t
> prevent stupid (and then wrong things).
> 
> The problem comes from the fact that we display the same information
> twice once as runtime (i.e. absolute time) once as duration (i.e.
> relative time). The question is: When I change one (say the runtime of a
> waypoint) what about the other waypoints? Shall we keep their runtime or
> their duration fixed? In the profile representation, we always move a
> single point, so we keep the other runtimes fixed. Is it the proper
> thing to do the same for the table? In that case it’s simple: Editing
> one of the fields should only be interpreted as having an influence on
> the runtime of that point, so adjust that, possibly resort the table and
> then recompute all durations after that. But maybe the user wants also a
> possibility to assume the durations of the other segments are fixed. In
> that case the runtime of all the following points would be changed as
> well.

We are over-designing this :-)
I think when editing the table, allow editing the duration but not the
runtime. Why? Duration never causes you to have to resort the entries.

The trick (and the thing that always messes us up with the gas assigned to
a "node" or "handle") that in the table you edit /segments/, but in the
graphical editor you edit /borders/, i.e., you move the point between two
segments.

Which reminds me, I need to check that we are doing the right things with
gases... 

> Maybe a way out would be that editing the runtime column implies the
> first behavior while editing the duration implies the second? This would
> at least prevent us from the bad case when the endpoint of a segment is
> moved before its start (by entering a value in the runtime column). What
> do you think?

See above. I don't want to allow editing absolute times in the table, but
I'm happy to allow editing relative times (durations). So I guess I'm
thinking just the other way around than you are.

> Bonus question: Shall we offer to change the duration as well in the
> graphical representation (e.g. when the shift key is pressed, not only
> the handle under the mouse but alle the following ones as well are
> moved)?

How many users do you think will a) figure out how to use it and b) use it
more than once in their lives?

/D