Sadly, no way to show them yet. But it would be nice to let people
enter them (and it would be doubly nice to have a dive computer that
does it at the surface), and then perhaps just do the "point browser at
google maps" thing.
Saving/parsing tested by hand-feeding the location of Enenui (Molokini
Crater) from google maps by hand into my divelog.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I never really liked 'diveclog' as a name - it's not like the C part is
all that important. And while I could try to just make up another slang
word for despicable person (in the tradition of naming all my projects
after myself), I just can't see it.
So let's just call it "subsurface".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently we print the temperature every five minutes. Especially with
dive computers that keep rather frequent temperature samples that means
that we have one more interesting data point that we don't label: the
surface temperature at the end of the dive.
This patch adds some logic to try to print the last temperature sample
that was recorded before the dive ended - unless that same value has
already been printed (to avoid silly duplications on dive computers with
less frequent sampling)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Just like we end depth and tank pressure plots once we are on the surface
(this is relevant for dive computers like the uemis Zurich that keep
recording samples after the end of the dive)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
stole and fixed Linus' code in the uemis XML importer
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is missing a ton of the information in the .SDA files It only
parses the divelog.SDA file, not the dive.SDA file It ignores the
information on the gas(es) used and all the data on the tanks.
It still draws some strange artefacts at the end of the dive
But it correctly hooks into the import dialogue, it gives you a file
select box (somewhere, I'm sure, a gtk developer cries quietly) and then
parses enough of this file to serve as a proof of concept.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dirk points out that equipment changes (cylinder size etc) do not cause
a proper repaint of the dive profile with new SAC information. The
reason? We haven't flushed the changes when the notebook changes from
the equipment page to the dive profile page.
Reported-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus clearly wanted to make SURE that we use /dev/ttyUSB0
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I'll get there. Shrink it down a bit, start adding notes and location,
and maybe put three per page. That might work.
.. or maybe I should just take a look at how others have done this.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ok, this is the ugliest f*&$ing printout I have ever seen in my life,
but think of it as a "the concept of printing works" commit, and you'll
be able to hold your lunch down and not gouge out your eyeballs with a
spoon. Maybe.
I'm just doing the cairo display as-is for the printout, which is a
seriously bad idea. I need to not try to do colors etc, and instead of
having white lines on a black background I just need to make thelines be
black on white paper.
But that would involve actually changing the current "plot()" routine,
which is against the point of the exercise right now. This really is
just a demonstration of how to add printing capabilities.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I have it in some of my notes, and Dirk seems to fill that in too, so
let's just show it, save it, and allow editing of it..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now we always create the MAX_CYLINDER sets of cylinder widgets. But we
don't actually pack them into the frame - that's a separate phase.
Right now we still do the stupid "always just pack two cylinders" thing,
but the idea is that we can pack just as many as the dive needs on a
per-dive basis.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This just always shows two cylinders, which is obviously bogus, but it's
a good test-case for the multi-cylinder case.
I need to figure out how to dynamically show the right number of
cylinders, but that also involves the notion of adding a cylinder in
order to fill out information that didn't use to exist.
That's lower priority - now the infrastructure seems to be there.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ok, now we have an array of them, and most of the time we pass the right
pointer back and forth.
There's still a couple of places that hardcode "gtk_cylinder[0]" as the
data, but by now they are mostly things that should iterate over all the
cylinders.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Create a "struct cylinder_widget" so that when we handle multiple
cylinders, we can match them up with the actual cylinder data;
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Let's try to be consistent about this. Make the parent of each widget
be a box. Maybe the frames come with boxes, but since I have no clue
about gtk, I'm going to just always create them by hand.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It doesn't really make much of a difference, but it can be visible
especially with lots of tight samples. Miter joins really look horrible
for acute angles.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Oooh, pretty.
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. without the actual text, because I'm a "random plots that cannot
actually be interpreted" kind of guy.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The build instructions are in the git commit log too, but let's make
them a bit easier to find.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
They get created when the equipment thing doesn't have a name for the
cylinder, but we don't want to save that lack of description.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's quite often obvious crap for the "doesn't exist" or "plain air" case.
So if it's reporting 100% O2, we just ignore it. Sure, it could be
right, but for the dives I have I know it's just libdivecomputer being
wrong.
Same goes for obvious crap like 255% Helium.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We're going to start to want to allocate dives and samples for the
libdivecomputer import too, so let's clean things up a bit for that.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. fill in the event parsing. This doesn't generate the fingerprint
like the example does, I just don't care about that yet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. 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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. 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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Some day.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Make it denser by putting the dive number/location in the frame label,
and make it size up and down more naturally.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I'm trying to make sure that we can shrink the main window and still get
a useful experience. Sometimes you have small bad netbooks when diving..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If you want to re-number your dives - either because they didn't have
any numbering at all, or because you forgot about other dives - you now
can.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We really do want to "pack" them, rather than use up the whole size. I
think.
I may end up playing around more with this.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When fixing the unit changes, I broke the dive buffering logic entirely
for switching between dives. Duh.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some people want to know how many dives they have under their belt, so
let's save and restore the dive number if it exists.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
