Or not. The temperature graph is usually ugly as hell, but Dirk has the
cool dive computer with lots and lots of temperature readings. Which
makes the graph a pretty graph, rather than a butt-ugly staircase like
mine.
Next time: get a dive computer with an OLED screen, and that can draw
pretty temperature graphs.
Libdivecomputer: start actually importing the dive data
So this actually reports the dive data that libdivecomputer generates.
It doesn't import special events etc, but neither do we for the xml
importer.
It is also slow as heck, since it doesn't try to do the "hey, I already
have this dive" logic and always imports everything, but the basics are
definitely there.
Instead of writing out the progress events, use them to update a real
progress bar.
Also, we need to handle gtk events while busy with the dive computer
reading. That should *probably* be done with a threading model, because
libdivecomputer does seem to have some timing sensitivity - I'm getting
"failure to read memory block" if I make that loop do the standard
while (gtk_events_pending())
gtk_main_iteration();
thing. Besides, even if we did do that loop, it would still cause
problems when the libdivecomputer code is stuck reading a serial line
that doesn't respond or whatever.
But for now this ugly hack is "good enough" to get further.
This actually gets me far enough that it prints out all the dives on my
dive computer. It doesn't actually turn them into real dives yet,
though - only a series of ugly 'printf's so far.
And it hangs after printing the last dive. So I'm doing something wrong.
.. this now registers the dive parsing callback, and starts to parse the
data. So I can see the last divetime on my Suunto Vyper Air now.
Still a lot more boilerplate stuff to go, though. The libdivecomputer
interfaces really are pretty insane: why should the caller set up the
dive parsing for each computer type, when libdivecomputer knows what
types it has? IOW, much of that boilerplate should be hidden inside of
libdivecomputer, rather than exposed to the user.
But whatever. I'm taking pieces from "examples/universal.c" as I go
along (it's under LGPL 2.1). I want to do it in small chunks just to
feel that I understand what's going on, rather than just blindly copying
it all.
Flesh out the libdivecomputer interfaces some more
.. start some error reporting, and register some early (empty)
callbacks.
This still doesn't actually do anything. But commit early, commit
often: when I start seriously breaking things, I want to have a "hey,
this still at least compiled" state.
Avoid using type 'gasmix_t': use 'struct gasmix' instead
libdivecomputer already uses 'gasmix_t' for its own gasmix thing. I
don't like th eway we step on each others name spaces, but hey, might as
well just use 'struct gasmix' and avoid the typedef.
Start some very initial libdivecomputer integration
Ok, so this is quite broken right now: it doesn't actually really *do*
anything, and it now requires that you have libdivecomputer all set up
and installed.
That is fairly easy:
mkdir ../src
cd ../src
git clone git://libdivecomputer.git.sourceforge.net/gitroot/libdivecomputer/libdivecomputer
cd libdivecomputer
autoreconf --install
./configure
make
sudo make install
but you may feel that this is not exactly useful considering that
nothing actually *works* yet.
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".
projects / ext / subsurface.git / log