The tec diving preference pane now allows us to set a partial pressure
threshold for each of the three gases. When the partial pressure surpasses
that value, the graph becomes red.
Fixes#12
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We now throw away redundant events, just as we throw away other redundant
data coming from the dive computer. Events are considered redundant if
they are less than 61 seconds apart and identical.
This also improves the display of the remaining events in the profile as
we now show the value of the event, if it is present (for example for a
deco event we show the duration of the deepest stop).
Finally, for events that define a range (so they set the beginning flag
and assume and end flag some time later) we no loger show the triangle but
assume that some other code handles visualizing them (as happens for the
ceiling events).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Based on suggestions from Linus (and a few iterations) we now simply have
the surface (i.e., background color / pattern) come down to where the
ceiling is. And we only do the angry red shading when the diver violates
the ceiling.
I think this looks much better.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Plot a red-shaded area on top of the depth profile to indicate the deco
ceiling (i.e., the area into which it isn't save to ascend at this point
of the dive.
So far this is of very limited use as libdivecomputer doesn't give us the
necessary information to plot this. I have sent patches for the OSTC to
Jef, hoping that he will include them in an update. I don't know how many
other dive computers will make this data available - I still need to add
this to our native Uemis support.
This commit also fixes two cut and paste errors in the previous commit
6540be9bd924 "Process ceiling events and store ceiling data in plot_info".
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The existing implementation failed on dive computers that did gas changes
based on events (instead of tracking them in the sample data like the
Uemis Zurich does that I tested the code with).
This commit moves the calculations slightly later in create_plot_info()
after the gas change events are processed and the plot_info data has been
fixed up. Now this works with the data from Linus' Suunto as well.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The pN2 print shouldn't have been committed, but I don't want to try and
rewrite all the commit history. Oh well.
The pressure scale I am ambivalent about. It seems that it should be
useful - but that would require guide lines that coincide with the values
which would really throw off the visual for me. So I added the code, but
left it disabled.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I can't remember why we initially did this instead of ending the
horizontal red line whith the last data point of the pressure profile. But
especially nuw with more graphs shown the one line that extends past the
end of the dive looked really silly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We always want to print absolute maxima and minima - but not when multiple
consecutive data points all have the same value (this happens, for
example, when printing a pHe plot on non-helium dives - or when the dive
profile includes a brief surface intervall which causes all the partial
pressures to be at their minimum).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Whatever I pick here, there will be dives where the different graphs end
up interfering with each other. I don't think there isn't an easy, generic
solution for this (but I can envision awesome non-easy solutions - they
just don't seem to be worth the effort).
But for most dives that I played with this seems to work pretty well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The algorithms attempt to identify "interesting" points where the user
might want to know the value of the graph.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Adjust the color for pN2 to the standard for this gas (black). We keep pO2
green (even though the ISO 32 color for that would be white). pHe is
marked in brown (which is the matching standard color).
Calculate correct partial pressures for the synthetic plot info points at
the beginning and end of the dive.
Minor fine tuning to the positioning / scaling of the temperature plot
when partial pressures are plotted.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So few of my dives are on air that at first I didn't notice - but for
those dives we set the o2 permille to 0 - which of course causes incorrect
(and extremely deadly) pO2 of 0...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Fairly simplistic change that modifies the way we calculate the "maxdepth"
for a particular dive as that is used to scale the plot vertically.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Not sure this is the best naming scheme (General Settings / Tec Settings)
but it's a start.
The idea is to have the settings that a recreational diver might care
about on the first page, and all the other stuff on the second one. Let's
see how this works out long term. For now I moved OTU over and added
toggles for the different partial pressure graphs (only the pO2 one is
implemented so far).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far this is done unconditionally. This already starts some of the
infrastructure for other gases, but so far only O2 is handled.
We also need a pressure scale on the right to make this useful - or we
need to do peek / trough pressure prints like we do for temperature and
depth.
Finally, I think I want to move the plot further down, maybe make the
whole plot area taller if we are plotting partial gas pressures as well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is intended to be unobtrusive, but add more information for people
who aren't satisfied with the numeric value we put inside the plot to mark
local peaks and troughs.
See ticket #9
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Here is what Linus reported:
I think you have made a mistake in trying to translate some of
libdivecomputer.c
Translating some of those things based on locale is *wrong*, because
they are saved in the XML file.
That covers at least the warnings: they'll get translated when you
import them, and then saved to the XML file as that translation, but
now if you start subsurface in another locale, they will not get
translated back.
So translating XML file contents is fundamentally buggy. It just
shouldn't be done.
So all the "translations" for the event handling are buggy, and
generate crap. Please don't do that. Leave them as English.
And of course he is absolutely right. However, instead of not translating
them at all, this commit fixes things a better way - we now mark the
strings for translation but store the original English strings everywhere
(in the in-memory data structure as well as in the XML file). Only when we
actually display something on the screen (in a tooltip or in the filter
dialog) do we actually translate the strings into the native language.
This should address both Linus' issue and the desire to have localized
event texts.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is just the first step - convert the string literals, try to catch
all the places where this isn't possible and the program needs to convert
string constants at runtime (those are the N_ macros).
Add a very rough first German localization so I can at least test what I
have done. Seriously, I have never used a localized OS, so I am certain
that I have many of the 'standard' translations wrong. Someone please take
over :-)
Major issues with this:
- right now it hardcodes the search path for the message catalog to be
./locale - that's of course bogus, but it works well while doing initial
testing. Once the tooling support is there we just should use the OS
default.
- even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets
can't seem to agree) I went with UTF-8 as that is what Gtk appears to
want to use internally. ISO-8859-15 encoded .mo files create funny
looking artefacts instead of Umlaute.
- no support at all in the Makefile - I was hoping someone with more
experience in how to best set this up would contribute a good set of
Makefile rules - likely this will help fix the first issue in that it
will also install the .mo file(s) in the correct place(s)
For now simply run
msgfmt -c -o subsurface.mo deutsch.po
to create the subsurface.mo file and then move it to
./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo
If you make changes to the sources and need to add new strings to be
translated, this is what seems to work (again, should be tooled through
the Makefile):
xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c
msgmerge -s -U po/deutsch.po subsurface-new.pot
If you do this PLEASE do one commit that just has the new msgid as
changes in line numbers create a TON of diff-noise. Do changes to
translations in a SEPARATE commit.
- no testing at all on Windows or Mac
It builds on Windows :-)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Tests have shown that the most multi-platform way to do printing with GTK is
to use GTK_UNIT_INCH (or GTK_UNIT_MM) with GtkPrintOperation. Tested on
Linux, OSX, Windows.
However this requires the appropriate scaling for Pango and Cairo to be done,
with separate plotting logic for printing and drawing on the screen. To achieve
that, profile.c:plot() now accepts a scaling parameter from type
"scale_mode_t" defined in "display.h".
Also due to new scale, small decimal numbers (such as 6.12345) cannot be well
stored in "cairo_rectangle_int_t" therefore it is replaced with
"cairo_rectangle_t", which uses doubles to provide Cairo with a drawing
area.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Minor whitespace cleanup.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Freedives can easily exceed the assumed ascent/descent rate, which
results in wacky dive profiles. Add a check to make the ascent and
descent fit within the duration of the dive.
Merge freediving tweaks (zoom in on short dives etc) from Maximilian
Güntner.
Trivial conflicts in display.h due to unrelated printing stuff just
happening to be added nearby.
* 'freediving-tweaks' of git://github.com/mguentner/subsurface:
moved zoomed_plot to display.h
plot the time with a fixed padding (leading zero)
updated/corrected comment
added "Zoom" button and improved scaling
fixed indentation
use increments that make sense for 600 seconds
Plot shorter (apnea) dives with a reasonable scale
The previous commit was a patch from Lubomir, which also had some
whitespace fixes (to go with some new whitespace bugs to replace them)
in it.
I removed the whitespace changes from that patch (don't mix whitespace
fixes with other fixes, unless they are on the same lines!) but decided
to look for other whitespace issues, and this is the result.
I left the non-C files alone, some of the spec and script files also
have whitespace at the end of lines etc.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This completely changes how we keep track of selected dives: instead of
having an array listing the selection ("selectiontracker") or trusting
the gtk selection information, just save the information about whether a
dive is selected in the dive itself.
That makes it trivial to keep track of the state of selection across
group collapse/expand events, or when changing the tree view model. It
also ends up simplifying the code and logic in other ways.
HOWEVER, it does currently (re-)introduce an annoying oddity with gtk:
if you collapse a dive trip that has individual selections, gtk will
forget those selections ("out of sight, out of mind"), and when you do
*new* selections, the old hidden ones remain.
So there's some games required to make gtk do sane things. We may need
to either explicitly drop selections when collapsing trips, or make sure
the group entry gets selected when collapsing a group that has
selections in it. Or something.
There may be other issues introduced by this too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The code iterates over a list that can be NULL, but happily dereferenced
it anyway. Oops.
This function really should be split up and commented more.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
It should be possible to have a certain limit where we
stop zooming so that short dives are visible as such
at first glance. Therefore a "Zoom" button has been
added to the "Log" menu along with a shortcut (Ctrl + "0").
The user can now zoom/unzoom the plot and is still able to
quickly distinguish short dives from normal ones when
browsing the log.
Signed-off-by: Maximilian Güntner <maximilian.guentner@gmail.com>
The time marker increments have also been changed to better values.
Also, display more time information for short dives.
Signed-off-by: Maximilian Güntner <maximilian.guentner@gmail.com>
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>
