One cannot expect #ifdef to work with enum values. So the code for
getting the salinity was basically never compiled in. And it was
putting it in the wrong location anyway (in the dive struct instead
of the divecomputer struct where it is expected).
I took the opportunity to add the reading of the atmospheric pressure
as well.
Signed-off-by: Patrick Valsecchi <patrick@thus.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This event is on when accumulating deco time. Once you reach the floor
deco time will start decreasing and the event will stop. Going below the
floor again will re-activate the event.
Also identify event type 13 in DM4 imports as airtime.
Signed-off-by: Michael Andreen <harv@ruin.nu>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This data structure was quite fragile and made 'undo' when editing
rather hard to implement. So instead I decided to turn this into a
QMultiMap which seemed like the ideal data structure for it.
This map holds all the dive computer related data indexed by the model. As
QMultiMap it allows multiple entries per key (model string) and
disambiguates between them with the deviceId.
This commit turned out much larger than I wanted. But I didn't manage to
find a clean way to break it up and make the pieces make sense.
So this brings back the Ok / Cancel button for the dive computer edit
dialog. And it makes those two buttons actually do the right thing (which
is what started this whole process). For this to work we simply copy the
map to a working copy and do all edits on that one - and then copy that
over the 'real' map when we accept the changes.
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>
- 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>
A couple of these could clearly cause a crash just like the one fixed by
commit 00865f5a1e1a ("equipment.c: Fix potential buffer overflow in
size_data_funct()").
One would append user input to fixed length buffer without checking.
We were hardcoding the (correct) max path length in macos.c - replaced by
the actual OS constant.
But the vast majority are just extremely generous guesses how long
localized strings could possibly be.
Yes, this commit is likely leaning towards overkill. But we have now been
bitten by buffer overflow crashes twice that were caused by localization,
so I tried to go through all of the code and identify every possible
buffer that could be affected by this.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we download dives with libdivecomputer, we create this strdup'ed
name of the model information, but we then re-use that (single) strdup
allocation for every dive we download. This works fine *until* you
start freeing those dives (possibly directly after the download because
they are redundant), at which point things go to hell in a handbasket,
since there is just the one allocation for all the different dives.
Fix by just doing another strdup() at the point where we assign the
model information to the dive computer.
Reported-by: Marc Merlin <marc@merlins.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The existing code forgot to reset the stopdepth to 0 which resulted in a
bogus safety stop being displayed on some divecomputers after the diver
finished their deco obligation.
Reported-by: Jan.Schubert <Jan.Schubert@GMX.li>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This centralizes all occurrences of Kelvin to dive.h and standardizes all
usages to milliKelvin.
[Dirk Hohndel: renamed the constant plus minor white space cleanup]
Signed-off-by: Jan Schubert <Jan.Schubert@GMX.li>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This moves the fields 'duration', 'surfacetime', 'maxdepth',
'meandepth', 'airtemp', 'watertemp', 'salinity' and 'surface_pressure'
to the per-divecomputer data structure. They are filled in by the dive
computer, and normally not edited.
NOTE! All actual *use* of this data was then changed from dive->field to
dive->dc.field programmatically with a shell-script and sed, and the
result then edited for details. So while the XML save and restore code
has been updated, all the displaying etc will currently always just show
the first dive computer entry.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
libdivecomputer doesn't actually seem to support air temperature
reporting at all, but at least for Suunto dive computers the air
temperature is recorded as the temperature for the first sample.
So since we already have vendor-specific libdivecomputer hacks, let's
just add that one as a rule. It may be that other divecomputers do this
too, so this adds it as a generic concept - it's just that right now the
flag for "air temperature in first sample" is only set for Suunto dive
computers.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
libdivecomputer has started giving the Suunto serial numbers in a
different format, which means that we have the same device with two
different serial numbers, and then we need two different ways of turning
the numerical entity into a string.
Look at the number pattern to see figure out which version of the format
it is that libdivecomputer is reporting, and turn it back into the
original format so that we can reliably give the right string for it.
This also mean sthat the device ID stays the same regardless of
libdivecomputer version.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This patch centralizes the definition for surface pressure, oxygen in
air, (re)defines all such values as plain integers and adapts calculations.
It eliminates 11 (!) occurrences of definitions for surface pressure and
also a few for oxygen in air.
It also rewrites the calculation for EAD, END and EADD using the new
definitons, harmonizing it for OC and CC and fixes a bug for EADD OC
calculation.
And finally it removes the unneeded variable entry_ead in gtk-gui.c.
Jan
Signed-off-by: Jan Schubert <Jan.Schubert@GMX.li>
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 clarifies/changes the meaning of our "cylinderindex" entry in our
samples. It has been rather confused, because different dive computers
have done things differently, and the naming really hasn't helped.
There are two totally different - and independent - cylinder "indexes":
- the pressure sensor index, which indicates which cylinder the sensor
data is from.
- the "active cylinder" index, which indicates which cylinder we actually
breathe from.
These two values really are totally independent, and have nothing
what-so-ever to do with each other. The sensor index may well be fixed:
many dive computers only support a single pressure sensor (whether
wireless or wired), and the sensor index is thus always zero.
Other dive computers may support multiple pressure sensors, and the gas
switch event may - or may not - indicate that the sensor changed too. A
dive computer might give the sensor data for *all* cylinders it can read,
regardless of which one is the one we're actively breathing. In fact, some
dive computers might give sensor data for not just *your* cylinder, but
your buddies.
This patch renames "cylinderindex" in the samples as "sensor", making it
quite clear that it's about which sensor index the pressure data in the
sample is about.
The way we figure out which is the currently active gas is with an
explicit has change event. If a computer (like the Uemis Zurich) joins the
two concepts together, then a sensor change should also create a gas
switch event. This patch also changes the Uemis importer to do that.
Finally, it should be noted that the plot info works totally separately
from the sample data, and is about what we actually *display*, not about
the sample pressures etc. In the plot info, the "cylinderindex" does in
fact mean the currently active cylinder, and while it is initially set to
match the sensor information from the samples, we then walk the gas change
events and fix it up - and if the active cylinder differs from the sensor
cylinder, we clear the sensor data.
[Dirk Hohndel: this conflicted with some of my recent changes - I think
I merged things correctly...]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This commit makes deco handling in Subsurface more compatible with the way
libdivecomputer creates the data. Previously we assumed that having a
stopdepth or stoptime and no ndl meant that we were in deco. But
libdivecomputer supports many dive computers that provide the deco state
of the diver but with no information about the next stop or the time
needed there. In order to be able to model this in Subsurface this adds an
in_deco flag to the samples. This is only stored to the XML file when it
changes so it doesn't add much overhead but will allow us to display some
deco information on dive computers like the Atomic Aquatics Cobalt or many
of the Suuntos (among others).
The commit also removes the old event based deco code that was commented
out already. And fixes the code so that the deco / ndl information is
stored for the very last sample as well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
They are useful for debugging things in libdivecomputer and this way it's
easier to match the data to specific points in the dive profile.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Without this deco could be mistaken as safety stop (in the case where
between two samples we go from a positive ndl to suddenly having a stop -
so we never reach ndl of 0)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When downloading from a dive computer, we fall back on matching the
exact date of the dive if we can't tell whether we already have that
exact dive computer data some other way.
However, if you have multiple dive computers and they are sufficiently
well synchronized, they might actually have the exact same date,
despite the fact that we do want to download both dive computers. We
do check the dive start to the exact second, so this sounds unlikely,
but with dive computers rounding time to the next minute etc, it's not
as unlikely as you'd think. Dirk hit it.
So when we match against date, do check that the dive computer might
actually be one we've already downloaded from. If we have full model
information, we can dismiss the "match date" logic.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should really be done in libdivecomputer, but that can't happen until
the API there gets extended to support tank sizes. So for now with this
code we manually parse the raw dive data (if downloaded via
libdivecomputer from a Cobalt) and setup the tank size ourselves.
This had relatively limited testing so far.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we have a dive computer model and dive ID, use that to match newly
downloaded dives against the existing dives.
Otherwise fall back to "exact date match" again, like we've always done.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Early in the libdivecomputer 0.3 development cycle Jef and I implemented
deco and ndl as events. That wasn't a wise design choice and we agreed to
switch this to be instead new sample types which makes much more sense
(and is much more aligned with the way we are handling them inside
Subsurface). So this commit tracks the change in libdivecomputer. Since
this happened during the development cycle there isn't a way to detect
this at compile time - so you need to make sure you have a matching
version of libdivecomputer when compiling Subsurface.
To make this easier: this commit of Subsurface requires a libdivecomputer
version that includes the libdivecomputer commit d5d44c1e0ffd "Convert
decostop / ndl to samples".
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This allows things to work for dive computers like the OSTC that give us
setpoint information in the sample, but not constant pO2 readings.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds the new members to the sample structure and fills them from
supported dive computers (Uemis SDA and OSTC / Shearwater Predator,
assuming you have libdivecomputer 0.3).
Save relvant values of this to the XML file and load it back. Handle the
new fields when merging dives.
At this stage we don't DO anything with this, all we do is extract them
from the dive computer, save them to the XML file and load them back.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Several blatant mistakes prevented this from ever working.
Now we correctly record ndl / stoptime / stopdepth in every sample and no
longer issue bogus events.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This commit changes the code that was recently introduced to deal with
deco ceilings. Instead of handling these through events we now store the
ceiling (which in reality is the deepest deco stop with all known dive
computers) and the stop time at that ceiling in the samples.
This also adds support for NDL (non stop dive limit) which both dive
computers that appear to give us ceiling / deco information appear to
give us as well (when the diver isn't in deco).
If the mouse hovers over the profile we now add support for displaying the
NDL, the current deco obligation and (if we are able to tell from the
data) whether we are at a safety stop.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I was a little too eager to add the deco feature to Subsurface. Jef and I
went back and forth a few more times and the definition of those events
changed. I guess I shouldn't have commited that code until the
corresponding libdivecomputer code had been pushed.
This commit now brings us in sync with the current master of
libdivecomputer (but should compile with 0.2 as well - only deco events
won't work then).
One issue that I see is that deco / ndl aren't really a good fit for the
event model. I actually disabled the drawing of the little yellow
triangles for ndl events as for example on the Uemis those events are
created whenever the remaining non stop time changes - and that can be
every few seconds.
The correct solution may be to treat this as a function of the samples,
but for now this works and is tested with both OSTC and Uemis SDA.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It's annoying to see water salinity data in the XML that isn't relevant,
and adding the default value just because the dive got downloaded from
libdivecomputer is definitely wrong.
We should set the water salinity explicitly only if we have it
explicitly set on the dive computer.
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>
Now that we have more complete dive computer information, we can use
that to match the dives we download, and stop with the hacky "Would we
merge this" check.
For XML files without the explicit dive computer information, go back to
checking the exact dive time.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This also knows how to save and restore multiple dive computers in the
XML data, but there's no way to actually *create* that kind of
information yet (nor do we display it). Tested by creating fake XML
files with multiple dive computers by hand so far.
The dive computer information right now contains (apart from the sample
and event data that we've always had):
- the vendor and product name of the dive computer
- the date of the dive according to the dive computer (so if you change
the dive date manually, the dive computer date stays around)
Note that if the dive computer date matches the dive date, we won't
bother saving the redundant information in the XML file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For now we only have one fixed divecomputer associated with each dive,
so this doesn't really change any current semantics. But it will make
it easier for us to associate a dive with multiple dive computers.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We used to avoid some extra allocations by just allocating the dive
samples as part of the 'struct dive' allocation itself, but that ends up
complicating things, and will make it impossible to have multiple
different sets of samples (for multiple dive computers).
So stop doing it. Just allocate the dive samples array separately.
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>
The divecomputer download code will stop at a matching dive (unless
you check the "Download all dives" option when downloading).
However, the matching dive is an *exact* match, which works well when
you have a single dive computer, but is a big pain when you have
multiple. What happens is that the date of the dive will be determined
by whatever dive computer you used first, and then downloading from
other dive computers will not match exactly, but will merge (if the
computers are within a minute of each other).
And that will continue to happen every time you try to download from
that other dive computer.
So use the same logic as for the automatic dive merging: consider
"within one minute" to be a matching dive. So don't download dives
that will be merged - unless the user asks for it.
We do want to have some way of saying "force download of all dives
from today" or something like that, I suspect. Because while I don't
want to re-download *every* dive, I might want to force-merge the last
<N> dives.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
"record_dive()" won't do that, since otherwise we'd mark the dive list
changed when we load it from an XML file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
This requires a patched libdivecomputer that can return salinity of the
water the dive was conducted in. Experimental patches exist that implement
this for the OSTC. The code is designed so that it simply defaults to salt
water if libdivecomputer doesn't include the feature.
The patch also fixes the dive merge code to merge two other recent
additions to the dive structure (surface_pressure and visibility).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Here is what Linus reported:
I think you have made a mistake in trying to translate some of
libdivecomputer.c
Translating some of those things based on locale is *wrong*, because
they are saved in the XML file.
That covers at least the warnings: they'll get translated when you
import them, and then saved to the XML file as that translation, but
now if you start subsurface in another locale, they will not get
translated back.
So translating XML file contents is fundamentally buggy. It just
shouldn't be done.
So all the "translations" for the event handling are buggy, and
generate crap. Please don't do that. Leave them as English.
And of course he is absolutely right. However, instead of not translating
them at all, this commit fixes things a better way - we now mark the
strings for translation but store the original English strings everywhere
(in the in-memory data structure as well as in the XML file). Only when we
actually display something on the screen (in a tooltip or in the filter
dialog) do we actually translate the strings into the native language.
This should address both Linus' issue and the desire to have localized
event texts.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is just the first step - convert the string literals, try to catch
all the places where this isn't possible and the program needs to convert
string constants at runtime (those are the N_ macros).
Add a very rough first German localization so I can at least test what I
have done. Seriously, I have never used a localized OS, so I am certain
that I have many of the 'standard' translations wrong. Someone please take
over :-)
Major issues with this:
- right now it hardcodes the search path for the message catalog to be
./locale - that's of course bogus, but it works well while doing initial
testing. Once the tooling support is there we just should use the OS
default.
- even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets
can't seem to agree) I went with UTF-8 as that is what Gtk appears to
want to use internally. ISO-8859-15 encoded .mo files create funny
looking artefacts instead of Umlaute.
- no support at all in the Makefile - I was hoping someone with more
experience in how to best set this up would contribute a good set of
Makefile rules - likely this will help fix the first issue in that it
will also install the .mo file(s) in the correct place(s)
For now simply run
msgfmt -c -o subsurface.mo deutsch.po
to create the subsurface.mo file and then move it to
./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo
If you make changes to the sources and need to add new strings to be
translated, this is what seems to work (again, should be tooled through
the Makefile):
xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c
msgmerge -s -U po/deutsch.po subsurface-new.pot
If you do this PLEASE do one commit that just has the new msgid as
changes in line numbers create a TON of diff-noise. Do changes to
translations in a SEPARATE commit.
- no testing at all on Windows or Mac
It builds on Windows :-)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There's no guarantee that gtk is thread-safe (apparently it can be
broken at least on Windows, even though it should be fine on top of X).
So don't update the progress bar directly from the dive computer import
code, instead just update the progress information in static variables,
and let the GUI thread update it while it does the idle loop polling
anyway.
Reported-by: Jef Driesen <jefdriesen@telenet.be>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
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>
I'm hoping most other dive computers are quicker to import from than the
Suunto I have, but mine can take minutes to import all the dives. Sure,
we have that nice progress bar, so it shows that it's doing something,
but it's not really showing *what* it is doing.
So instead of showing just "Parsing dive X", let's show the date of the
dive. That way, when it takes two minutes to import all the dives, at
least you can see "oh, it's going back to the dives of last year" and it
then feels like you have some good reason for the delay.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of using printf() to print the string updates ("Parsing sample
data" etc), introduce a function to show those strings in the graphical
progress bar itself.
Subsurface hasn't been a text-mode application in a long time ;)
This partially fixes the second todo entry from commit b0ba22a068
("Show dive import error messages in the import dialog") and generally
makes for a more helpful import - at least for the largely error-free
cases.
Sadly, the messages that really come from within libdivecomputer itself
(like "suunto_vyper2.c:193: Failed to receive the answer.") when things
go really wrong are not caught. libdivecomputer does have a notion of a
logfile (set with "message_set_logfile()"), but that ends up being
really inconvenient.
Maybe we could use some pipe setup or something. Oh well.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
