Add function libdc_buffer_parser() intended to parse raw data buffers
prepared for libdivecomputer. We have to commit elsewhere the necesary
assembly tasks to achieve consistent data.
Actually only OSTCTools import makes use of this feature. Uwatec families
have been included as I expect to make use of this function for sample
parsing in datatrak import (and, may be in a far future, smartrak).
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Taken as is from libdivecomputer exaples/common.c to improve verbosity
on libdc return codes.
Intended to be used on error messages shown to the user on main window
complementarily to those messages managed by dev_info().
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While downloading from DC the user sets the vendor and model. In
imports, this is not possible. The parser has to figure out somehow at
least the dive computer model used in a dive basis, as it can even change
over time, and a log file can include several different models.
We will use this structure in import tasks to ensure that data
passed to libdc are consistent with what it expects to find.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This needs to become a string in libdivecomputer - but for now let's just
keep the integers so we can parse it elsewhere when we know which model it
is - the generic parsing into a string is completely bogus and needs to go.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is not the right way to get serial numbers and firmware versions. The
libdivecomputer interface here is simply broken. Those ARE NOT numbers.
But until we have the capability in libdivecomputer to return reasonable
strings to us, this could be a stop gap measure to help us understand how
these are formatted.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Not only does it make it look more like the libdivecomputer downloaders,
but the uemis downloader needs it in order to support all the flags we
have. Notably "download into private trip".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a checkbox for the divecomputer download dialog that allows you
to tell the download to put the newly downloaded dives into a trip of
their own. That in turn will disable the dive merging with any existing
dives, which means that you will not mix up your newly downloaded dives
with any old dives.
That, in turn, is very convenient of you know that some of the dives were
done by other divers (or from testing that happened during servicing etc),
or the dive dates etc were wrong because the dive computer date had reset
due to battery changes etc.
Once you have all the dives in a private trip of their own, you can then
fix them up (delete dives you don't want to merge etc), and then after all
the data is ok you might want to merge the cleaned-up results with
previous trips etc, and then manually ask subsurface to merge the dives or
whatever.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I know everyone will hate it.
Go ahead. Complain. Call me names.
At least now things are consistent and reproducible.
If you want changes, have your complaint come with a patch to
scripts/whitespace.pl so that we can automate it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
* ensure include guard to every header
* comment endif guard block
Signed-off-by: Boris Barbulovski <bbarbulovski@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For some devices, the event data contains important data that is
required for parsing the dives, but which is not present in the full
memory dump.
Signed-off-by: Jef Driesen <jefdriesen@telenet.be>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On a 32bit machine this will truncate values with MSB set to 0x7fffffff
Fixes#164
(thanks to Linus for pointing me in the right direction)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- remove the build flags and libraries from the Makefile / Configure.mk
- remove the glib types (gboolean, gchar, gint64, gint)
- comment out / hack around gettext
- replace the glib file helper functions
- replace g_ascii_strtod
- replace g_build_filename
- use environment variables instead of g_get_home_dir() & g_get_user_name()
- comment out GPS string parsing (uses glib utf8 macros)
This needs massive cleanup, but it's a snapshot of what I have right now, in
case people want to look at it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
libxml headers include ICU headers and ICU has C++ code. If it detects
__cplusplus, it will start declaring C++ templates and whatnot, which
aren't allowed under extern "C".
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This behaves somewhat differently from the Gtk version - still needs
more investigation. But at least now it's hooked in.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I think it's self explanatory - When user clicks on
'Cancel', the interface will wait for the trhead to quit
then will close itself.
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
This is the skeleton code for a non-blocking ui-thread
It already creates the first-thread ( 'do not block the ui' )
and the second thread ('download from the dive computer')
We can in the future merge both in the same place - I didn't
want to do that now because the download function is written
in the libdivecomputer.c code, and I cant just transform that
to a QThread and use signals, so I used two threads for that.
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
After the 3.1 release it is time to shift the focus on the Qt effort - and
the best way to do this is to merge the changes in the Qt branch into
master.
Linus was extremely nice and did a merge for me. I decided to do my own
merge instead (which by accident actually based on a different version of
the Qt branch) and then used his merge to double check what I was doing.
I resolved a few things differently but overall what we did was very much
the same (and I say this with pride since Linus is a professional git
merger)
Here's his merge commit message:
This is a rough and tumble merge of the Qt branch into 'master',
trying to sort out the conflicts as best as I could.
There were two major kinds of conflicts:
- the Makefile changes, in particular the split of the single
Makefile into Rules.mk and Configure.mk, along with the obvious Qt
build changes themselves.
Those changes conflicted with some of the updates done in mainline
wrt "release" targets and some helper macros ($(NAME) etc).
Resolved by largely taking the Qt branch versions, and then editing
in the most obvious parts of the Makefile updates from mainline.
NOTE! The script/get_version shell script was made to just fail
silently on not finding a git repository, which avoided having to
take some particularly ugly Makefile changes.
- Various random updates in mainline to support things like dive tags.
The conflicts were mainly to the gtk GUI parts, which obviously
looked different afterwards. I fixed things up to look like the
newer code, but since the gtk files themselves are actually dead in
the Qt branch, this is largely irrelevant.
NOTE! This does *NOT* introduce the equivalent Qt functionality.
The fields are there in the code now, but there's no Qt UI for the
whole dive tag stuff etc.
This seems to compile for me (although I have to force
"QMAKE=qmake-qt4" on f19), and results in a Linux binary that seems to
work, but it is otherwise largely untested.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The device combo box is only necessary for the Uemis Zurich, and dive
computers using serial communication. For dive computers using IrDA or
USB communication, this combo box causes only confusion for the users.
Starting with libdivecomputer version 0.4, there is an api to query the
transport type, which can be used to enable/disable the device combo box
based on the selected model.
Signed-off-by: Jef Driesen <jefdriesen@telenet.be>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- rip all Gtk code from qt-gui.cpp
- don't compile Gtk specific files
- don't link against Gtk libraries
- don't compile modules we don't use at all (yet)
- use #if USE_GTK_UI on the remaining files to disable Gtk related parts
- disable the non-functional Cochran support while I'm at it
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It turns out that the serial number returned by libdivecomputer isn't
really the serial number as interpreted by the vendor. Those tend to be
strings, but libdivecomputer gives us a 32bit number.
Some experimenting showed that for the Suunto devies tested the serial
number is encoded in that 32bit number:
It so happens that the Suunto serial number strings are strings that have
all numbers, but they aren't *one* number. They are four bytes
representing two numbers each, and the "23500027" string is actually the
four bytes 23 50 00 27 (0x17 0x32 0x00 0x1b). And libdivecomputer has
incorrectly parsed those four bytes as one number, not as the encoded
serial number string it is. So the value 389152795 is actually hex
0x1732001b, which is 0x17 0x32 0x00 0x1b, which is - 23 50 00 27.
This should be done by libdivecomputer, but hey, in the meantime this at
least shows the concept. And helps test the XML save/restore code.
It depends on the two patches that create the whole "device.c"
infrastructure, of course. With this, my dive file ends up having the
settings section look like this:
<divecomputerid model='Suunto Vyper Air' deviceid='d4629110'
serial='01201094' firmware='1.1.22'/>
<divecomputerid model='Suunto HelO2' deviceid='995dd566'
serial='23500027' firmware='1.0.4'/>
where the format of the firmware version is something I guessed at,
but it was the obvious choice (again, it's byte-based, I'm ignoring
the high byte that is zero for both of my Suuntos).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This simplifies the vendor/product fields into just a single "model"
string for the dive computer, since we can't really validly ever use it
any other way anyway.
Also, add 'deviceid' and 'diveid' fields: they are just 32-bit hex
values that are unique for that particular dive computer model. For
libdivecomputer, they are basically the first word of the SHA1 of the
data that libdivecomputer gives us.
(Trying to expose it in some other way is insane - different dive
computers use different models for the ID, so don't try to do some kind
of serial number or something like that)
For the Uemis Zurich, which doesn't use the libdivecomputer import, we
currently only set the model name. The computer does have some kind of
device ID string, and we could/should just do the same "SHA1 over the
ID" to give it a unique ID, but the pseudo-xml parsing confuses me, so
I'll let Dirk fix that up.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The code pretended to support this for libdivecomputer based downloads,
but it had never been hooked up when the native Uemis downloader was
implemented. When I finally decided to close that feature gap I realized
that the original code was, shall we say, "aspirational" or "completely
bogus" and therefore never worked.
So instead of just hooking up the code for the Uemis downloader I instead
implemented this correctly for the first time for both libdivecomputer and
the native Uemis downloader.
In order not to have to mess with multithreaded Gtk development I simply
opted for a helper function that fires on a 100ms timeout and have it end
the dialog without a response. This way we can run the dialog while
waiting for the download to finish, still update the progress bar and
respond in a useful manner to the user clicking cancel.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This will hopefully not be something we need often, but if we improve
support for a divecomputer (either in libdivecomputer or in our native
Uemis code or even in the way we handle (and potentially discard) events),
then it is extremely useful to be able to say "re-download things
from the divecomputer and for things that were not edited in Subsurface,
don't try to merge the data (which gives BAD results if for example you
fixed a bug in the depth calculation in libdivecomputer) but instead
simply take the samples, the events and some of the other unedited data
straight from the download".
This commit implements just that - a "force download" checkbox in the
download dialog that makes us reimport all dives from the dive computer,
even the ones we already have, and an "always prefer downloaded dive"
checkbox that then tells Subsurface not to merge but simply to take the
data from the downloaded dive - without overwriting the things we have
already edited in Subsurface (like location, buddy, equipment, etc).
This, as a precaution, refuses to merge dives that don't have identical
start times. So if you have edited the date / time of a dive or if you
have previously merged your dive with a different dive computer (and
therefore modified samples and events) you are out of luck.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The include of libdivecomputer/utils.h breaks the compilation
of subsurface as it is no longer present in the latest version
of libdivecomputer.
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
For this you need to get the current libdivecomputer tree, reconfigure,
build and install it first. But this cleans up some of the silly error
handling too, and has just a single "dc_device_close()" call etc, rather
than duplicating that (and the new dc_context_free()).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Subsurface doesn't compile on OS X any more, because libdivecomputer
changed the way the header inclusion works: the include path from
pkg-config no longer includes the final "libdivecomputer" component, and
instead of doing
#include <header.h>
for libdivecomputer headers, we're now supposed to do
#include <libdivecomputer/header.h>
instead. Which is cleaner anyway.
The reason this only bit us on OS X is that I never trusted pkg-config
that much for non-system libraries on Linux (maybe it works, maybe it
doesn't, I've seen it go both ways), so on Linux we just used our own
version of the include path, and thus weren't affected by the
libdivecomputer config change.
Clean up the includes while at it - we no longer need (or want) the
device-specific header files, since we just use the generic functions.
Reported-by: Grischa Toedt <toedt@embl.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This does mean that you have to build subsurface against a new version
of libdivecomputer, and that version is likely going to have various
slightly incompatible changes. But the new interfaces allow for easily
adding new supported dive computers without subsurface having to be
updated for each new vendor and model, so some slight pain is definitely
worth it this time.
I'm not even going to try to have some backwards-compatible version
here, the libdivecomputer interface changes are so extensive. Native
enumeration of devices is just the smallest part of it: the constants
and types that libdivecomputer uses now have much nicer names that all
start with DC_ or dc_, so you don't get the kinds of name clashes we had
with "gasmix_t" etc.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. not in the main window. And leave the import dialog open, so that
you can either try doing it again, or cancel. This makes it much easier
to re-try a failed dive import, and actually makes the failure more
obvious too.
Todo:
- make the "Ok" button change to "Retry" when an error happens
- try to see if we can catch the actual status update messages from
libdivecomputer and show them too in the import dialog. Right now
they are printed out to stderr by the library.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I don't know about other dive computers, but the Suunto Vyper Air is
slow as hell to import all the dives from. And libdivecomputer seems to
be importing dives "most recent first", so this just makes it stop
importing dives when it finds a dive that we've already seen.
Caveat: libdivecomputer has this fancy notion of "dive fingerprints",
and claims that's the way to do things. That seems to be overly
complicated, and not worth the bother.
If you worry about the import finishing early due to already having some
dives with the same date in your dive list, just import starting from an
empty state, and thus get a pure "dive computer only" state with no
early out. Then you can just load the old dives afterwards, and depend
on subsurface merging any duplicates.
But for normal operation, when you just want to import a couple of new
dives from your dive computer, the "exit import early when you see a
duplicate" is the right thing to do.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As reported by Mauro Dreissig, the progress bar doesn't work and causes
a SIGSEGV due to a missing allocation. The code broke when Dirk
separated out the GUI from the core code, and I hadn't tried
divecomputer downloads since.
Reported-by: Mauro Dreissig <mukadr@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The following are UI toolkit specific:
gtk-gui.c - overall layout, main window of the UI
divelist.c - list of dives subsurface maintains
equipment.c - equipment / tank information for each dive
info.c - detailed dive info
print.c - printing
The rest is independent of the UI:
main.c i - program frame
dive.c i - creates and maintaines the internal dive list structure
libdivecomputer.c
uemis.c
parse-xml.c
save-xml.c - interface with dive computers and the XML files
profile.c - creates the data for the profile and draws it using cairo
This commit should contain NO functional changes, just moving code around
and a couple of minor abstractions.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
