This is the hackiest thing ever, unless you count the previous code that
was even hackier (and just called the gtk main routine at random
places).
The libdivecomputer library is not really set up to be part of the gtk
main loop, and cannot afford (for example) to have lots of mainloop
events while it's parsing. Some dive computers are very timing
sensitive for the communication.
So just start a thread for doing the libdivecomputer stuff, and just
continually call the gtk main loop while that thread is running. I'm
sure we could actually use some gtk signalling thing to make the thread
exit do the right thing, but instead we just poll the status every
100ms.
I did say it was hacky. It does seem to work, though. No more
temporary graying out of the windows when they don't react in a timely
manner because libdivecomputer does some blocking operation.
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>
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>
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>
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>
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>
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>
