This is very simplistic as far as placement of the text goes.
It makes the plot_text function somewhat more generic.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Text notes need to be last, so that they don't get stepped on by the
other graph elements.
Also, separate the depth text plot out into a function of its own.
Tidier that way.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use a 10-minute window *or* when the depth has reversed sufficiently to
make the max we've found interesting.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add some actual numbers to the depth plot too. Do it by finding the
deepest points (within a five-minute rolling window), and show the
depths of those points.
Sure, we could have just labeled the depth markers, but this seems
nicer. But what do I know - I'm not exactly famous for my GUI design.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Only draw the pressure line to the final data point
(duration / end.mbar) if we haven't already drawn samples
past that point (as the UEMIS records pressure data for a
number of additional samples after the actual dive has ended)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
[ Changed to use 'last actual drawn sample time that had pressure
data' instead of 'last sample time' - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Each caller ends up needing it, and I missed another one. So rather
than update the other caller, just do it in dive_list_update_dives() and
we can stop worrying about it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Looks like Linus misinterpreted the first UEMIS xml files I sent him.
The date_time appears to be in local time - so the time zone info can be
ignored (that seems strange, but it worked for the dives I tested it
with)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We did this when loading from the command line, but not when loading
through the file load menu item.
Reported-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'open-files' of git://github.com/nathansamson/diveclog:
Report errors when opening files
Make it possible to load multiple files at once.
Open File works. I refactored the code and introduced a new type. I never used it as a pointer (their was no real reason), but I'm not really satisfied.
This is just a very rough draft. It imports all the main stuff I
noticed, but I'm sure it drops a ton of other stuff.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of having each import source recognition routine set a separate
flag for that import source, just enumerate them and set them in one
variable.
I'm adding yet another xml importer - divinglog.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There's a big comment there now about what is going on. It took me a
while to understand how the crazy seven-tank uemis dive computer
information actually works.
So the Uemis computer has 4 different "tank profiles":
- single tank air (0)
- single tank nitrox (1)
- two-tank nitrox (2)
- three-tank nitrox (3)
and the computer always lists all seven tank cases (because that's how
you fill them in).
Depending on the "gas.template" you are supposed to then *use* just one
particular profile. Why the computer doesn't just give you the tanks
for that one profile, who knows? It seems to be more of the same "Uemis
dive data isn't so much about the dive, it's about dive computer state"
mentality.
So we first get the profile information, and then based on that we need
to pick the right tanks from the set of seven that we're presented with.
All clear?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This makes the xml save-file look way nicer: it's both smaller and
better organized. Using individual xml nodes for random small details
is silly.
The duration even parses exactly the same, because it still ends up
being '.depth.duration' (now it's the 'duration' attribute of the dive
node, it used to be the 'duration' child node of the dive node).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Doing per-dive cylinder start/end pressures is insane, when we can have
up to eight cylinders. The cylinder start/end pressure cannot be per
dive, it needs to be per cylinder.
This makes the save format cleaner too, we have all the cylinder data in
just one place.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
..as suggested by Nathan:
"I also wanted to "zebra" color the divelist by setting the rules-hint
to TRUE. but I noticed it was already set explicitly to FALSE (even
if this is the default).
If this is just an accidental copy paste from some tutorial you can
experiment (set it to TRUE) and see what you like most."
It was indeed just copy-paste from some tutorial, and the zebra-coloring
does look nicer, doesn't it?
Suggested-by: Nathan Samson <nathansamson@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of always using three decimal digits, use 1-3 digits. But do
use at least one, even for integer numbers, just because it makes it so
much clearer that we're dealing with potential fractional values.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I don't necessarily want to show three decimal digits when one or two
would do. So prepare for that by using a helper. This doesn't actually
change the printout yet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is some seriously crazy stuff. Instead of making sense as a
divelog, the uemis xml makes more sense as a "dive computer settings
dump".
And I guess I can see why they'd do that. But it makes parsing it just
incredibly annoying. The thing is more of a "these are the
configurations I support as a dive computer thing" than a "this was the
tank you were diving with".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
