I'll want to also add a way to override/set the cylinder type: both
manually by just setting a size in liters, and by picking from some list
of standard cylinder sizes.
For example, it looks like most of my dives are marked as having
12-liter cylinders. That is probably some default from Suunto Dive
Manager, or from whatever Dirk did. It's almost certainly not right for
any of them: as far as I know, the standard cylinders for Lahaina Divers
(which is likely most of the warm water dives) are AL72's for air, and
AL80's for Nitrox.
That would be a 10L and a 11.1L tank respectively, afaik. I don't know
what a 12-liter tank would be or where that size comes from.
Anyway, the LP85+ tank designation for some of the dives looks more
likely: that's one of the common sizes I've used for local dives. So
the size of that thing is much more probably correct.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We don't want to override potentially more exact values for water
temperature etc either. The sample save interval may be longer than
some internally kept state of key per-dive values like that.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. and sort based on the 'time_t' value itself.
This allows us to use a more compact date format that doesn't need to
sort alphabetically, because sorting by date is always based on the date
value. So we can use just a two-digit year, and skip the seconds, to
keep the column narrow, while still sorting correctly.
Also, "Depth" is a nice header string, but it is wider than the column
itself, which makes the whole column wider than necessary. So put the
units in the header instead of in the string, keeping things narrow.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'ui-improvements' of https://github.com/nathansamson/diveclog:
Split the dive list in columns. Columns are sortable now (name = date, depth, duration)
Remove the redundant frames in the notebook. Closes#9
Use a pane so the dive list can be made wider or smaller to the users wishes
* 'compiler-warning' of https://github.com/nathansamson/diveclog:
Removed the unused startemp and enttemp calculations. This fixes a compiler warning too.
Fix up trivial conflict in dive.c due to the temperature simplification
(commit 9961c7f89c: "Remove redundant temperature readings").
So we don't want to save working pressure, but cylinder type knowledge
would be lovely and useful. And we can probably make a good initial
guess, or at least let people fill it in later.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It was a mistake to save it - and I did it just because other dive
managers did. It's a totally nonsensical measure, and nobody cares.
The only thing that matters is the size of the cylinder, and the
*actual* pressures. Those give actual air consumption numbers, and are
meaningful and unambiguous.
So the "working pressure" for a cylinder is pointless except for two
things:
- if you don't know the actual physical size, you need the "working
pressure" along with the air size (eg "85 cuft") in order to compute
the physical size. So we do use the working pressure on *input* from
systems that report cylinder sizes that way.
- People may well want to know what kind of cylinder they were diving,
and again, you can make a good guess about this from the working
pressure. So saving information like "HP100+" for the cylinder would
be a good thing.
But notice how in neither case do we actually want to save the working
pressure itself. And in fact saving it actually makes the output format
ambiguous: if we give both size and working pressure, what does 'size'
mean? Is it physical size in liters, or air size in cu ft?
So saving working pressure is just wrong. Get rid of it.
I'm going to add some kind of "cylinder description" thing, which we can
save instead (and perhaps guess standard cylinders from input like the
working pressure from dive logs that don't do this sanely - which is all
of them, as far as I can tell).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I'm aiming to really differentiate in dive log software by making my XML
export files be *clean*, dammit.
That means that we don't have random names, we don't have crazy random
units, and we don't have redundant information.
So when the temperature doesn't change, just don't report it. That's
already what "no sample" means, just clean things up.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Uppercase first letter for each label word
Tweak the paddings for easier reading
Rename File menu to Log menu
Add a separator before Quit in the Log menu
Remove frame in extended diving info and add 6px padding
Signed-off-by: Hylke Bons <hylkebons@gmail.com>
* 'fix-entries' of https://github.com/nathansamson/diveclog:
Word wrap the info textview. Also do not show the scrollbars if not necessary.
Change location to a text entry instead of text view.
It's not called 'parse' any more. And I think I should rename 'divelog'
too to something more unique. Right now the working name for the
project is 'diveclog' (kind of like 'jdivelog') , but I'm not convinced
that the "C implementation" part is really important enough to make a
point of long-term.
"subsurface"? I don't know. Maybe I should follow the "name all
projects after myself" mantra. "divenut"?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It never actually triggered anything for me, but any buffered data might
be lost, especially if you force-exit the application after saving a
dive log.
This probably explains a corrupted (truncated) dive file report from
Nathan Samson.
Reported-by: Nathan Samson <https://github.com/nathansamson>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I didn't even notice that the "File" part of the file menu no longer
showed up, since the keyboard accelerator for ^S worked fine.. But
apparently there's no default label associated with GTK_STOCK_FILE in
gtk2, so the "File" text went away with the conversion to GtkUIManager
in commit 4d62478e14 ("Use the newer GtkUIManager for menu creation.")
The addition of a Quit menu entry with the associated keyboard
accelerator also makes ^Q "just work".
Of course, if we actually tracked dirty state etc, we could perhaps ask
the user whether they wanted to save or something. But I'm not exactly
famous for my GUI chops, so ..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's all calculated anyway, and for the same reason we don't bother even
parsing it at load time, we really shouldn't bother saving it either.
The only thing you can do with that value is "check if the percentages
add up to 100%", and so what?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of just tracking gasmix, track the size and workng pressure of
the cylinder too.
And use "cylinder" instead of "tank" throughout.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The computer may track "real" max depth more closely than it tracks
samples. So we trust the non-computed mean/max depths more than the
computed ones.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now the dive profile plot *really* needs some units. The pressure is
just a random line otherwise.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
..since this is now on github, might as well tell people what they need
to compile it, and warn them about the state of the project.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I really don't understand the packing rules. This does not look like
what I intended.
Oh well.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If given multiple dives at the same time, just de-dup the dives. This
happens when you've dumped the whole dive-computer several times, and
some dives show up in multiple dumps.
When de-duping, try to avoid dropping data. So if one dive has notes
attached to it, and the other one does not, pick the notes from the dive
that does have them. Obvious stuff like that.
The sample merge is also written so that it should be possible to merge
two dives. Which we don't actually do yet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It looks like the "units.pressure" setting is only about the units that
things are *shown* in on the wrist computer: the units in the file are
always in bar (or rather, centi-bar).
Which is definitely the right thing to do, and means that we shouldn't
care about parsing the units setting. It's purely about how something
is shown, not about parsing.
That's probably true of the other units too, but let's see when I have
more data to go on.
Also, parse water temperatures and tank pressure.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We still end up guessing based on magnitude of the value, though: it
might be 'bar' or 'mbar', we end up picking one or the other based on
just how big the value is.
I should make it look at any possible explicit units too, since at least
with good xml, they exist. Of course, the only good xml I've seen so
far is the one we generate ourselves ;)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I think I'll need to re-organize the handling of per-format code, but
for now we just mix it all up.
The uemis conversion is also questionable even for just the small parts
I do. Does it really do "centiPSI"? That sounds crazy. I'm waiting for
Dirk to send me some actual human-readable output from the dives, right
now some of it is just rough guesses.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If it exists, it really does help identify the dive. At least it does
for me: "local or Maui"?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I think it should be legal xml, but whatever. libxml2 is very unhappy,
and complains when loading - even if I escape them. So let's just
replace the low escape characters with '?'.
The only thing to ever care was my test-case, I suspect.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Let's make it a goal that the XML we output is pretty. That clearly was
never a goal for the Suunto XML, but we can be oh-so-much-better than that.
I still don't love XML, but let's try to make the best of a bad situation,
and take pride in what we do.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use the "empty element" form for samples that don't have any events
associated with them (and none do, right now). This avoids that
annoying "</sample>" crud.
And output the units in the output helpers, so that you can't forget
them even if you try.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When we see a number like 23.145, we'd better always also see a unit.
It's just good practice. So add 'min' to duration (and use only two
digits for number of seconds), and 'm' to depth.
And write the date in international standard format.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The standard way to write a date is yyyy-mm-dd, which is unambiguous and
sorts correctly.
We parsed that right in the 'datetime' case, but not in the normal date
case. And we do want to use that in our output format, exactly because
it's standard.
And also parse 'duration' for the dive duration. It's what we use when
saving, it just so happened that we ended up not parsing it right, but
then picking it up from the samples instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
