There are a couple of issues with this commit:
GtkEntry should emit the 'changed' signal when it is modified (so that
changes in the preferences get applied right away) - but that doesn't
appear to be working consistently.
Also, this doesn't appear to affect the deco of any dives that I try it
with. So my guess is something is wrong with the underlying deco
algorithm. That's diappointing.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This also initializes the N2 tissue saturations to correct numbers
(setting them to zero was clearly silly).
With this commit we walk back in the dive_table until we find a surface
intervall that's longer than 48h. Or a dive that comes after the last one
we looked at; that would indicate that this is a divelist that contains
dives from multiple divers or dives that for other reasons are not
ordered. In a sane environment one would assume that the dives that need
to be taken into account when doing deco calculations are organized as one
trip in the XML file and so this logic should work.
One major downside of the current implementation is that we recalculate
everything whenever the plot_info is recreated - which happens quite
frequently, for example when resizing the window or even when we go into
loup mode. While this isn't all that compute intensive, this is an utter
waste and we should at least cache the saturation inherited from previous
dives (and clear that number when the selected dive changes). We don't
want to cache all of it as the recreation of the plot_info may be
triggered by the user changing equipment (and most importantly, gasmix)
information. In that case the deco data for this dive does indeed have to
be recreated. But without changing the current dive the saturation after
the last surface intervall should stay the same.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Usually dive computers show the ceiling in terms of the next deco stop -
and those are in 3m increments. This commit also adds the ability to chose
either the typical 3m increments or the smooth ceiling that the Bühlmann
algorithm actually calculates.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
