The get_trip_date_string() formatted, as the name implies, the date
of a trip. It was passed a number of parameters and had only one
caller, which would also add the location if it existed.
Therefore, move all that logic into the helper function and
name it get_trip_string().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Dirk reports that some Windows users have had odd corruption in the
commit messages in the cloud storage. They make no sense at all unless
there is some very weird Windows library bug.
The prime suspect is 'vsnprintf()' returning a negative error when the
target buffer is too small (rather than the proper "this is how much
space it would need"). That is a very traditional C library bug that I
thougth had been fixed everywhere, but there doesn't really seem to be a
lot of other likely causes.
So let's make our membuffer code be defensive against bad libraries that
return negative error numbers from vsnprintf.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Android can't scan for classic BT devices, so when BT support was first
added, we simply didn't use the discovery agent at all and relied on the
list of paired BT devices provided by Android.
This still worked fine for a lot of BLE devices that allowed 'bonding'
with the Android device - similar to pairing. But some BLE devices (like
the Shearwater Peregrine) don't support bonding and so our Android code
didn't see them at all.
With this commit we start a BLE only scan on Android to add to the list
of already paired devices.
Fixes: #2974
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We certainly should log errors and the complete list of discovered
devices.
Also, it's good practice to set a specific search time (I picked three
minutes). This way we won't constantly scan and drain resources.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We call the same helper from two spots. Once when we report the already
paired BT devices on Android, and once from the deviceDescovered signal
for the discovery agent. Let's make sure we can tell where the info came
from.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far we saved timestamps by their 64-bit value as decimal strings.
Change this to a user readable format. The parsing routine still
supports decimal numbers.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To save datetime-based filter constraints to git or XML,
it is preferrable to use human-readable representations.
Therefore, add helper functions to format / parse timestamp_t
64-bit values in the "YYYY-MM-DD hh:mm:ss" format.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When importing a divelog, import filter presets. If there are
equal names, import only if the presets differ. In that case,
disambiguate the name. This made things a bit more complicated,
as comparison of filter presets had to be implemented.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The filter widget was caching whether the filter was active and
used that flag to calculate the "# dives shown" string. Move this
directly to the DiveFilter class to remove interdependencies and
to unify with mobile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This is mostly copy and paste of other git loading code. Sadly,
it adds a lot of state to the parser-state. I wish we could pass
different parser states to the parser_* functions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
On the mailing list it was decided that users might want to
move their filter presets across computers via the cloud.
Notably, in the future one might access statistics on mobile and
these might by controlled by filter presets.
The git save routines use the same string formatting as the
XML save routines. The string formatting is found in
core/filterconstraint.cpp. Thus, duplication of code and
inconsistencies should be minimized.
Each filter preset is saved into a file in the "02-Filterpresets"
folder in the root of the git repository.
Each file consists of one "name" line, zero or one "fulltext" line
and zero or more "constraint" lines.
The modes, types and the actual payload is controlled via attributes.
Thus, a preset file might look like this:
name "test"
fulltext mode="substring" query="clown"
constraint type="location" stringmode="starstwith" data="mafia"
constraint type="sac" rangemode="range" negate data="5000,10000"
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This is a bit painful: since we don't want to modify the filter
presets when the user imports (as opposed to opens) a log,
we have to provide a table where the parser stores the presets.
Calling the parser is getting quite unwieldy, since many tables
are passed. We probably should introduce a structure representing
a full log-book at one point, which collects all the things that
are saved to the log.
Apart from that, this is simply the counterpart to saving to XML.
The interpretation of the string data is performed by core
functions, not the parser itself to avoid code duplication with
the git parser.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The parse_* functions should probably be declared in parse.h.
Arguably, parse_xml_init() and parse_xml_exit() should be moved
to an init.h file, however that doesn't yet exist.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Declare the function in the header file corresponding to the source
file where the function is defined.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Users might want to move their presets with there log-file. Therefore,
save the presets to the log. The alternative would be to save them
to the preferences. However, on the mailinglist it was decided that
moving the presets to a mobile device is a wanted feature.
The XML saving code has a rather reasonable interface, therefore
this turned out to be pretty easy to implement.
The filter presets are saved into a
<filterpresets>
...
</filterpresets>
block
Each individual preset is saved into a
<filterpreset name='...'>
...
</filterpreset>
Block with a unique name attribute.
Each preset contains zero or one fulltext and zero or more constraint entries.
The type and mode(s) are controlled by attributes, the "payload" is saved in
the block. Note that all the formatting is done by functions in core/filterconstraint.c
and not the parser itself.
A preset in the XML file might look like this:
<filterpreset name='test1'>
<fulltext mode='startswith'>Train</fulltext>
<constraint type='planned'>0,0</constraint>
<constraint type='sac' range_mode='range' negate='1'>5000,10000</constraint>
</filterpreset>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add undo commands to add / edit / delete filter presets.
These are styled after the other undo commands: On changes,
the UI is informed by DiveListNotifier signals. Editing is
a simple std::swap of values.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a rudimentary list of filter presets to the core. The list
is sorted by name. Access is provided via a C interface so that
the presets can be written to the git and XML logs. Internally,
the list is realized by a C++ vector for convenience (euphemism for
laziness).
Morover, a C++ interface is provided for the UI. Currently names of
the presets cannot be edited, since this would mean that the order
of the list changes. This may be implemented later if required.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Switch the mobile code to use the constraint-based filter. The one
thing that is still commented out is dive-site mode, since mobile
doesn't (yet) have a dive-site edit feature. And even if it had,
the dive list probably wouldn't be shown at the same time.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Replace the static filterwidget with a list of filterconstraints.
The first attempt of using a table widget failed, because Qt's
table delegates are dysfunctional. It's not that they are bad, they
just don't work at all.
Therefore, this code "simulates" a table in that on addition / deletion
of constraints it keeps track of the rows of all constraints so
that each constraint-widget can be associated with a row of the
constraint model.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a model that keeps track of a list of filter constraint and makes
them accessible from Qt. Sadly, this is mostly repetitive boiler-plate
code, but this is due to Qt's model/view-API, which is a perfect example
of how *not* to design a reasonable modern API.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Adds a filter constraint object to the core, which represents one
constraint the user can filter dives with. The plan is to write these
constraints to the XML and git logs. Therefore, this code is written
in C-style except when it comes to handling strings and dates, which
is just too painful in plain C.
There is one pointer to QStringList in the class, though when compiled
with C, this is simply transformed into a pointer to void. Granted,
that smells of an ugly hack. However it's more pragmatic than
self-flaggelation with C string and list handling.
A filter constraint is supposed to be a very general thing, which can
filter for strings, multiple-choice lists, numerical ranges and date
ranges.
Range constraints have a range mode: less-or-equal, greater-or-equal
or in-range. Text constraints have a string mode: startswith, substring
or exact.
All the data are accessed via setter and getter functions for
at least basic levels of isolation, despite being written with
a C-interface in mind.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
So far, the fulltext-query structure only saves an canonicalized
upper-cased version of the query. However, if we want to save the
fulltext query to the log (filter presets) or want to restore an old
fulltext query, we have to store the original query. We don't want
to confront the user with the mangled upper-cased version.
Therefore, also save the original version.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To support the new filter code, add helper functions that turn timestamps
into year and day-of-week to core/time.c.
Internally, these functions simply call utc_mktime() to break down the
timestamp and then extract the wanted value. This may appear inefficient,
but testing shows that modern compilers are quite effective in throwing
away the unneeded calculations. FWIW in this respect clang10 outperformed
gcc10.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The cylinder model is used both in the planner and the
equipment tab. We have three preferences for the pO2 that
is used to compute MOD: In the planner, there is one for
the bottom part of the dive and another one for deco.
Those are set in the planenr UI. There is another value,
controlled in the Tec Prefernces. That one should be
used in the equipment tab rather than the one from
the planner.
Fixes#2984
Signed-off-by: Robert C. Helling <helling@atdotde.de>
I think we only have one dive computer that supports GPS data right now:
the Garmin Descent Mk1. It reports the dive coordinates as "GPS1" and
"GPS2" for the entry point and exit point respectively.
Often GPS1 is missing, because the dive computer may not have gotten a
GPS lock before the diver jumped into the water, so when that happens
we'll use GPS2 for the dive site location. But when GPS1 exists, we
should prefer that.
And that's what we already did in logic in dc_get_gps_location(), but
for the initial dive site created at download time, we just picked any
divecomputer reported string that started with "GPS". And since GPS2 is
reported after GPS1 by the Garmin Descent, it would end up overwriting
the entry point that we _should_ have preferred.
Add the same kind of "explicitly prefer GPS1" logic to the initial dive
download case as we already had elsewhere.
Reported-by: @brysconsulting
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
gcc complained about two constructs of the kind
remote_id && SSRF_INFO("...");
And while I am not a fan of excessive warnings, I must say
it has a point here. That's just code obfuscation. In fact,
it appears that the condition was wrong - the SSRF_INFO
should probably be invoked if remote_id is NULL. The way
it was written it would be invoked if it was *not* NULL.
Change both instances to unfancy if statements.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The water type strings were static and therefore passed through
gettextFromC::tr() before main(). One would hope to get a warning
in such a case, but this is not the case.
Therefore, use the QT_TRANSLATE_NOOP macro to register the strings
in Qt's translation system and translate the list when needed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The clock is only valid in ascent. In each cycle of the
'critial volume algorithm' it re-initialized to the
bottom time at the beginning of deco. So the time spent
on bailout should be added to this bottom time.
Thanks to Coverty for spotting this.
Coverity-scan: CID-362079
Signed-off-by: Robert C. Helling <helling@atdotde.de>
When an undo command selected invisible dives, a current dive outside
of the list of selected dives was chosen. This could have the very
unfortunate effect that the current dive was set, though not selected.
From an UI point of view this meant that the dive was displayed, but
edits would not be registered.
Change the setClosestCurrentDive function to select the current dive.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For Android the Qt Bluetooth code seems to work just fine. And for macOS
nothing appears to work right now, but at least the Qt implementation compiles
and links.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The Qt based implementation apparently got broken at some point and now fails
to connect to rfcomm dive computers like the Shearwater Petrel.
This uses the libdivecomputer rfcomm backend. Tested to work with bluez on
Linux as well as with the native Windows implementation.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
At least Shearwater Cloud seems to use multiple formats for sample time
recorded in the database. Sometimes the time is in seconds, sometimes in
milliseconds, and sometime it is something I have no idea about. Thus
switching to calculating the sample id myself and using sample interval
to calculate the actual sample time. Seems to be more reliable than
trying to guess what format Shearwater is using for this specific dive.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
ExifTools (and probably other meta-data editors) modifies the
mvhd creation date, but leaves the individual creation dates
in the tracks unchanged. Therefore, use the mvhd atom.
Reported-by: Eric Tanguy <erictanguy2@orange.fr>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This extends the uuid matching to the low-level characteristics too, so
that we can ignore the McLean Extreme characteristics that aren't
interesting.
It also renames the uuid matching to be about a "uuid_list" rather than
being about the service we're matching, since we're now using it for
other uuid's than just services.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Silly typo with a missing 'i' in 'uuid' that happened when I wrote this
code originally, and that compiled fine thanks to the error being
duplicated with cut-and-paste to all relevant places.
Fix it now, since I'll extend the uuid matching to the actual
characteristics for the McLean Extreme.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It turns out that contrary to what the documentation states, a few languages
are still only using the 'qt' translation. But those exist for all languages,
so we need to first search for the 'qtbase' translations, and only if that
fails do we try to load the 'qt' translations.
And even that will fail for languages in which Qt simply isn't localized (like
Dutch).
To make the code more readable, the check for 'US English' was moved earlier as
there is no point to look for a Qt translation for that (simply doesn't exist).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We were still using the 'qt' translations instead of 'qtbase' as we should have
been using since forever - it's a little unclear from reading the documentation
when in the Qt5 life cycle this happened, but definitely several years ago.
These are the strings used in situations where Qt already provides us with text
(e.g., the entries in the 'Subsurface' menu on Mac, or the button labels in
many dialogs).
Additionally we didn't try hard enough to find those translations in cases
where they are bundled with the app; so basically all scenarios except for
Linux distro specific packages or 'build from source' on macOS or Linux were
not going to work, even after addressing the qt->qtbase conversion.
But of course the developers pretty much all fall into those last two
categories. Still, I cannot believe we never fixed this in all those years...
To make it more obvious if we still aren't finding the Qt translations this
commit also makes that warning be shown in all cases, not just when running in
verbose mode.
Fixes#2954
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The logic to retrieve gas changes from Shearwater cloud database is
detecting only when the O2/He chnages. This change will grab the initial
gas. (Problem was only shown when there was a gas changee in the log, so
cingle cylinder dives were working fine.)
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Gas change is done to the cylinder we just found and not the last
cylinder. Also switching the variable name to index as we are actually
using that value outside the loop.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Shearwater apparently stores correct pressures nowadays, so getting rid
of a hack to import double pressures.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
This will ignore the gas changes that would be caused by Shearwater
cloud saving rows with 0 values in them.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
A sample log I received contains a lot of rows with 0 values in it. This
will ignore the obviously bogus ones. (However, we might miss the first
sample if that is recorded at time 0.)
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
core/device.h was declaring a number of functions that were related
to divecomputers (dcs): creating a fake dc for manually entered dives
and registering / accessing dc nicknames. On could argue whether
these should be lumped together, but it is what it is.
However, part of that was implemented in C++/Qt code in a separate
core/divecomputer.cpp file. Some function therein where only
accessible to C++ and declared in core/divecomputer.h.
All in all, a big mess. Let's simply combine the files and
conditionally compile the C++-only functions depending on
the __cplusplus define.
Yes, that means turning device.c into device.cpp. A brave soul
might turn the C++/Qt code into C code if they whish later on.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The functions matchDC() and matchModel() were never implemented.
Remove their declarations.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The function *looks* like it is a dive function. However, in reality
it implicitly works on the global device list. Therefore, it is
thematically more aptly located in device.h with the other device
functions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The SAC factor is only used for minimal gas calculations which
don't make sense in the CCR context.
Additionally, make bailout stop for at least minimum switch
time or problem solving time.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
In a previous commit, auto-filling of weight based on type was
changed to be only performed if the user hadn't already set a
weight, by testing for weight=0.
However, when the user edited the type and tabbed back and forth,
that counted as an edit and therefore the weight would not
change anymore.
To refine this, introduce an "auto_filled" flag to the weightsystem,
which is set if the weight is automatically filled and cleared if
the weight is edited. Update the weight if it was zero *or* auto-filled.
The flag is not saved to disk, but that should be acceptable. If the
user saves and reloads, we can assume that they meant the weight
to be set to the default value.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
