The Diving Log temperature reading is in Fahrenheit for the samples (for
the per-dive water/air temperature it's in Celsius). But it seems to
have a bug where a lack of a sample has been turned into 32 Fahrenheit
(which is 0 celsius). This is despite the dive itself having a water
temperature of 8 degF.
Just throw away those bogus freezing temperatures. Sure, they can
happen, and ice divers are crazy - but in this case I know it's just an
error in the log, and it looks very much like a Diving Log bug.
The LP85+ name is not something we'd normally want to recognize. The LP
cylinder names all tend to be by the "+" pressure anyway, and that's
what we do in the equipment handling naming.
When we change units, we need to flush any currently active dive
information in the old units, and then carefully reload it in the new
units.
Otherwise crazy stuff happens - like having current cylinder working
pressure values that are in PSI because that *used* to be the output
unit, but then interpreting those values as BAR, because we changed the
units.
Also, since we now properly import working pressure from Diving Log,
stop importing the (useless) cylinder description. The Diving Log
cylinder descriptions are things like "Alu" or "Steel". We're better
off just making up our own.
Finally, since Diving Log has cylinder size in metric, make sure that we
do the "match standard cylinder sizes" *after* we've done all the
cylinder size conversions to proper units.
Oh Gods. Why are all other scuba programs so f*&% messed up?
The Diving Log cylinder working pressure is in bar - which is all good.
But their pressure *samples* are in PSI. Why the h*ll do people mix up
units in the same damn file like that? I despair at the pure
incompetence sometimes.
I suspect the pressure samples aren't "really" in PSI: they are probably
in some user-specified units.
Add more static cylinder types - and pick them up from the dive log
This adds a few more predefined cylinder types to the static list, but
perhaps more importantly, if we try to show a cylinder description that
we haven't seen before, we automatically add that description to the
list as well.
This way, if people have their own cylinder types, our cylinder
management will automatically figure them out and make it easy to enter
them.
NOTE! It might be best to add the new cylinder description at dive log
load time, rather than at 'show' time.
Add new cylinder models to the cylinder model store
We also need to actually fill the model store with the cylinder models
we have in our dive lists to begin with.
This makes it all *trivial* to add a new cylinder model: just use a new
description, fill in the size and working pressure, and you're done.
The type automatically gets filled in, unless that description already
existed (in which case we leave it alone).
If the output units are set to cuft and psi, then we should show the
cylinder size and pressure properly.
NOTE! In the absense of pressure data, we *always* show the cylinder
volume in liter. There's no way to convert it to imperial units, since
the imperial units are not in physical size, but in air volume
normalized to surface pressure..
Now that we don't mess up import, we can save the cylinder working pressure
We used to have the heuristic that if we saw a cylinder working
pressure, then the cylinder size would be in cuft. Which meant that we
couldn't export our working pressures, because it would mess things up
on import.
But working pressure is actually nice to know, if you ever work with
cylinders in imperial units. So now that the import is fixed, add the
working pressure to the export.
First (broken) try at actually tracking cylinder types
This doesn't actually change the cylinder type info in the dive, because
it's too broken for that. Instead it prints out what it would change
things to.
The gtk2 notion of text input focus is *really* odd. Why is the
cylinder type sometimes selected, and sometimes not?
Make it about general equipment management, and start hooking up
functions to show new equipment information when changing dives (and to
flush changes to equipment information for the previously active dive).
Nothing is hooked up yet, and it's now showing just one (really big)
cylinder choice, so this is all broken. But it should make it possible
to at least get somewhere some day.
Ok, so it's not connected to anything yet, and the tank choices (that
don't do anything) are some random hardcoded collection, but maybe it
will do something some day.
That seems to be the gtk2 way. Whatever. diveclog ends up defaulting
to metric units, because we all know that's the right thing to do.
However, I learnt to dive in the US, so I'm used to seeing psi and feet.
So despite the sane defaults, I want diveclog to use the broken imperial
units for me.
Dirk likes purple. I mean - Dirk REALLY likes purple.
And what's better than "purple"? You got it: "funky purple".
So this shows the one- two- and three-minute min/max information in some
seriously funky purple fringing. It's not really necessarily meant to
be serious, but it's a quick hack to visualize the data until we figure
out what to *really* do with it.
Start analyzing depth profile: smoothing and time-based min/max/avg
This turns the depth profile into a generic "plot_info" and calculates
minima, maxima and averages over 1-, 2- and 3-minute intervals for each
point. It also creates a smoothed version.
We currently don't actually show the results, but that's the next step..
The way cairo does scaling is really really inconvenient, and one of the
things in cairo that is fundamentally mis-designed.
Cairo scaling always affects both coordinates and object sizes, and the
two can apparently never be split apart. Which is very much not what we
want: we want just coordinate scaling.
So we cannot use 'cairo_scale()' to scale our canvas, because that
screws up lines and text size too. And no, you cannot "fix" that by
de-scaling the line size etc - because line size is one-dimensional, so
you can't undo the (different) scaling in X/Y.
Sad. I realize that often you do want to scale object size with
coordinate transformation, but quite often you *don't* want to.
Yeah, we could do random context save/restore in odd places etc, but
that's just a sign of the bad design of cairo scaling.
Work around it by introducing our own graphics context with scaling,
which does it right. I don't like this, but it seems to be better than
the alternatives.
Use a recursive (instead of iterative) minmax depth finder
This is a bit more natural, and makes it much easier to do scale
independence. In particular, I want to make it possible to grow and
shrink the graph, and this should make it particularly simple to react
by giving more or fewer minmax points.
Do output unit conversion in the dive info window too
This should take care of it all, unless I missed some case.
Now we should just save the default units somewhere, and I should do the
divelist update much cleaner (instead of re-doing the divelist entirely,
it should just repaint it - now we lose the highlited dive etc).
Honor depth unit settings when plotting the depth profile
This shows the depth properly in meter or feet depending on unit
selection.
It also changes the horizontal depth rulers to be at 10m/30ft intervals
rather than the previous 15ft. With the textual depth markers, the
horizontal lines aren't as important any more.
Fix drawing artifacts with dives that have samples past the dive duration
The UEMIS Zurich SDA keeps recording samples for quite a while after the
dive ended. These provide no additional information, but confuse our
drawing algorithm as they can cause us to draw both the depth and tank
pressure plots beyond the right edge of our canvas.
Stop drawing if sample->time.seconds is larger than dive->duration.seconds.
Add some information about properly formatted commit messages
It does seem like a lot of github users are not used to good commit
message rules, and may never have used git for a project that actually
cares about good logs and nice summary lines.
Scott Chacon [Tue, 6 Sep 2011 19:32:51 +0000 (12:32 -0700)]
Add more explicit contributing explanation
Most developers on GitHub are not used to projects that use the Signed-off-by convention.
They do, however, tend to read the READMEs to see which conventions the author prefers
to follow. If you are explicit about what you prefer in the README with easy to follow
instructions, it is more likely people will follow those conventions.
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.
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>
Repaint the dives in dive_list_update_dives() instead of in callers
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.
Merge branch 'open-files' of git://github.com/nathansamson/diveclog
* '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.
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.
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.
Turn dive depth, temperature and duration into xml attributes
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).
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.
"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?
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.
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.
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".
Make a guess at the cylinder description from the size and pressure
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.
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.
Generate date string for the dive list dynamically
.. 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.
Merge branch 'ui-improvements' of https://github.com/nathansamson/diveclog
* '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
Merge branch 'compiler-warning' of https://github.com/nathansamson/diveclog
* '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 9961c7f89ce6: "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.
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).
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
Merge branch 'fix-entries' of https://github.com/nathansamson/diveclog
* '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.
Update gitignore for the name-change of the executable
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"?
projects / ext / subsurface.git / log