Pull miscellaneous fixes, mostly UI stuff from Mikko Rasa.
Both this and the pull from Pierre-Yves Chibon created a "Save As" menu
entry and logic. As a result, there were a fair number of conflicts,
but I tried to make the end result somewhat reasonable. I might have
missed some semantic conflict, though.
Series-acked-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
* 'misc-fixes' of git://github.com/DataBeaver/subsurface:
Add a separate "Save as" entry to the menu
Changes to menu icons
Improved depth info for dives without samples
Divide the panes evenly in view_three
This fixes the bug that triggered the SIGSEGV that Linus worked around
earlier. I had forgotten to update this call path to the
edit_multi_dive_info function.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This calculates a mean depth for the dive with a fixed ascent/descent
rate and an assumption that all of the bottom time is at the maximum
depth. It's not much, but it allows some derived values such as SAC to
make more sense.
The depth profile for such dives is now also generated with the same
assumptions instead of putting the samples at fixed percentages of the
dive duration.
Signed-off-by: Mikko Rasa <tdb@tdb.fi>
Fix ugly printout, give colors proper names, make grid lines and alert
marker easier to see, and specify printer colors independently.
Signed-Off-By: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
The profile colors were defined all over the place, so I put them all in one spot. I'm unsure if this is the best solution to that problem, but I guess it's a step in the right direction.
Signed-Off-By: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
The profile colors aren't very pretty, and the grid lines are too thick.
This commit tries to improve that.
Signed-Off-By: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
We do all the pressures in mbar, which has plenty of precision for
interpolated pressures - even when we then do our discrete integration
over many samples.
However, when we calculate those interpolated pressure points, we should
make sure that we round the result correctly, otherwise the consistent
rounding errors (from truncating the FP value into our integer mbar
values) will result in a final pressure that is noticeably off in ugly
ways (ie "end pressure set by hand to 750 mbar, but shown as 748").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit abdee5b1b8.
There's no point in doing random hacks. Instead, do the intermediate
pressure calculations with proper rounding instead of always truncating
to mbar. With the math done correctly we have enough precision that the
end result of the pressure interpolation doesn't have the kind of errors
that caused Dirk to try to fix things up later.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
While printing the last pressure in the calculated sequence may seem more
logical, given that the discrete series will create some amount of error
this simply looks wrong. Instead we pick the end pressure that was
manually set.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Some parts of the existing code used the depth at the time of the sample
to calculate the sac rate - it makes much more sense to use the average
depth. But that requires us to loop over the entries and average the
individual sac rates per segment instead of just using the beginning and
end depth of the multi-segment interval we use for smoothing purposes.
This may seem like a subtle detail, but it does in fact matter when we
plot the synthetic tank pressure values that we create when we have no
tank pressure data in the samples.
Another detail we change here is to not artificially start with a forward
looking segment of the full SAC_WINDOW but instead just start with the
first two data points and then simply let the time window grow until it
hits SAC_WINDOW - at which point it becomes a sliding window.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This changes the algorithm that picks the sac color to consider
+/- 1 l/min to be the same color (before the color changed every
time you crossed above or below the average which looked silly with
our synthetic "constant sac" values as those are discrete and oscilate
around the average.
This also changes the order in which things are drawn so so that the
pressure plot goes over the depth profile plot (so the red shading of the
dive no longer changes the color of the tank pressure plot).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Use rgb_t for the sac colors, create a new set_source_rgb_struct function
and use that for the velocity values (in the depth plot) as well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Linus suggested that instead of using absolute SAC values to base the
color on (which forced us to pre-define which SAC rates are green and
which are red) we should color the tank pressure plot relative to the avg
SAC rate of that dive - which I think makes the coloring much more useful
to spot when on your dive you were doing well and when you were not.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Similar to color indicating vertical speed in the profile plot we now use
color in the tank pressure plot to indicate current SAC rate.
We use a 45 sec sliding window to make sure we cover at least two breaths
for each current SAC sample to avoid artificial oscillation based on
breathing rhythm for corputers with high sample resolution.
Not sure about the color coding that I'm using right now - it's green-ish
for SAC rates under 15l/min ~= .55cuft/min and turns yellow and red as you
go higher. That seems to work well for me, but for other divers this may
be way off (or at least not as useful). Maybe this should be configurable?
This is a lot more diver specific than the vertical velocity where there
are clear recommendations based on safety considerations on what is good
and bad.
As a side effect, this removes the color coding that showed you whether
you were looking at pressure data from samples (green) vs. interpolated
pressure data (yellow). Not sure if people really want to see that. We
might be able to indicate this differently (I am thinking different line
width or transparency or something along those line)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Some dive computers randomly drop samples. That was no problem unless it
was the LAST sample. We work around that now
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
.. and fix the maxpressure to actually look at *all* the cylinders, so
that if you don't have sample data, but rely onmanually set cylinder
pressures, it now really is the max of all the cylinders.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We no longer look at the start and end pressure for a tank, if the tank
has valid pressure data in its samples (which makes sense). Sadly that
breaks the current pressure interpolation code. With this patch most of
those problems should be fixed.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- make the text a lighter color so it stands out more
- change the heuristic when we print text to include both relative change
in temperature and time since the last text was printed
- print the first temperature we encounter
- allow an ending temperature to be printed if the last printed
temperature was before the 75% mark of the dive
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I thought we had fixed this before - but I guess it got broken again
somewhere. We now make sure that the plot_info ends on an entry with
depth 0.
Added test14 to verify the fix.
Also fixed cut'n'paste errors in a few test dive files.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In some situations we could end up with no sample pressure and no
interpolated pressure at time = 0. This is now fixed.
Fix notes in test dive the exposed the issue.
Also change the code in create_plot_info to keep the number of samples and
the number of corresponding pi entries in separate variables. This avoids
future changes from breaking if they assume they can access
dive->sample[nr_samples - 1] (which is a reasonable assumption to make).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This was exposed by the test dives, but it shows up in small ways with
real dives from some dive computers like the Suunto Vyper Air.
We now insert synthetic plot_info entries that match the gas change event;
to make this look smoother we insert either two events (one for the old
tank, one a second later for the new tank) if there is no sample at the
time of the event, or one additional event (and move the real sample back
by one second) if there is a sample at the time of the event.
This does expose another issue with some dives from Linus' computer where
the pressure in the samples dips below the end pressure noted for the tank
- which creates an odd "yellow up-tick" at the end of using the first tank
in the plot. Maybe we should not insert a synthetic "last of old tank"
event if we have a sample with valid pressure in the last NN seconds
before the gas change?
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we have more than four identical depth readings, the old code would see
those as local maxima and minima and print spurious depth values in the
profile plot.
Yes, in real sample data identical readings won't happen - but in
synthetic data they can and there this looks really bogus.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Finally getting more consistent overall in how we convert between the
different units and how we decide which units to display.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Designed along the lines of get_depth_units - except we don't define a
specific number of digits to show.
Use this in the one spot we need it right now in profile.c
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We used to have the dive plot have two "filler" entries at the beginning
and the end, and indeed that is how they are allocated. However, we fix
up "pi->nr" later to be "lastindex+1", where "lastindex" is the index of
the time we surface.
So when we loop over the plot entries, we actually need to loop all the
way to the end: use "i < pi->nr" instead of "i < pi->nr-2".
We still do have the two extra filler entries at the beginning, though.
So depending on the loop, we might want to start at entry 2.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Right now it just plots something ridiculous, the code is really just
meant to be an example. We migth be able to plot a traditional
staircase plot and make it look somewhat saner by taking mean depth into
account (if it exists).
Right now it just plots a (skewed) rectangular dive profile using the
max depth and total time. Which is obviously insane.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When creating the plot_info, the 'entry' variable pointing to the last
plot_info data was not initialized (because there was no data to fill
in), and was then incorrectly used to fill in the last tank pressure.
We also used to look at 'dive->sample[0].cylinderindex' even if no
sample[0] necessarily existed.
Reported-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Right now they are displayed in one hbox which doesn't work if you have
many events - but the code itself works and correctly toggles the events
on and off.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We don't have a way to actually configure this in the app, yet, but
toggling the bits in the debugger shows that this works, so commit this
code now.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
First step to being able to filter the events that we display in the
profile. We could (in theory) walk all the dives in the divelist when we
need this data, but it seems much more convenient to have them in an array
in one place.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
* 'ui' of git://github.com/dirkhh/subsurface:
Disable sorting by dive number
Fix oversight in preference implementation
Make columns for temperature, cylinder, and nitrox optional
Show dive number in dive list
Improve time marker handling and add printing of some time labels
We now draw time markers at most every 5 min, but no more than 12 markers.
For convenience we do 5, 10, 15 or 30 min intervals.
This allows for 6h dives - enough (I hope) for even the craziest divers -
but just in case, for those 8h depth-record-breaking dives, we double the
interval if this still doesn't get us to 12 or fewer time markers.
We label the first and then every other time marker with the minute text.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Dirk wrote the multi-cylinder support assuming that the dive computer
always gives the selected cylinder index in the sample data - that's
what his Uemis does, and it makes sense for any dive computer that
supports multiple pressure transmitters.
However, the other case is a dive computer where the pressure samples
are all from cylinder 0, and any other cylinder will have the starting
and ending pressure set by hand. And the gas change events show when
the cylinder change happened.
So this creates a "turn gas change events into pressure sample fixups"
phase just before we actually analyze the pressures. That way the
pressure analysis can alway sdo the right thing, regardless of how the
data was originally stores in the dive.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
For the dive computers that give cylinder change events, we want to
re-write the cylinder index and pressure information with the event
information before we start analyzing the pressures. So instead of
filling the plot info and analyzing in one loop, split it up into two
phases. We'll do the "fix up cylinder pressure info based on events" in
between those phases.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The code keeps track of the segments of time when a specific tank was used
and interpolates the pressure values for that tank based on a simulated
average SAC rate for the times in which no pressure readings are
available.
This changes the way we used to plot the pressure when only beginning and
end pressure of a tank are known; it used to be a straight line, now it is
a sloped line where the steepness of the slope is proportional to the
depth at that point - which is much more realistic.
We also plot the pressures in two colors now. The old green for pressure
data that came from the input file (that is not the same thing as saying
it came from the computer - divelog for example appear to create pressure
readings in the samples even if it only has beginning and end pressure).
Interpolated values are plotted in yellow. If you have a sub-standard dive
computer which has a frequently failing pressure sensor, you can now tell
the parts of the plot where data was missing and we are filling in.
The function that prints the pressure text labels had to be completely
redone as it previously assumed one tank for the whole dive and
simplisticly printed that tank's start and end pressure at the beginning
and end of the profile plot with the y-values being the maximum and
minimum pressure...
This commit introduces a custom simplistic single linked list data
structure to keep track of the pressure information per segment - Linus
hated the idea of using GList for this purpose, and I have to admit that
in the end this was very straight forward to implement and made the code
easier to read and debug.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This isn't right if you switch back to the same cylinder multiple times,
but for the first time it kind of works - just take the beginning
cylinder pressure if we have one.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Too much cut-and-paste, as Dirk points out. With multiple cylinders,
we're not necessarily going to start at time zero.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It doesn't actually do multiple cylinders correctly yet, but it should
be a nice framework for it. And accidentally (not) it also ends up
drawing the final line for the end pressure of a single-cylinder dive
that has been fixed up by hand too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We draw a little red triangle (of hardcoded size - not sure if this SHOULD
scale with the size of the plot... I like it better if it doesn't) to the
left of an event.
We then maintain an array of rectangles that each circumscribe one of
those event triangles and if the mouse pointer enters one of these
rectangles then we display (after a short delay) a tooltip with the event
text.
Manually creating these rectangles, maintaining the coordinate offset,
checking if we are inside one of these rectangles and then showing a
tooltip... this all seems like there should be gtk functions to do this by
default... but if there are then I failed to find them. So instead I
manually implemented the necessary logic.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
