This should have been caught by our build check, but it turns out that
that one isn't correctly reflected in its Travis status.
Oops.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A very very trival fix, for a mysterious issue. When loading
GPS fix data from the server, the string date was parsed with
the format "yyy-M-d". And no, the "yyy" is no typo here, but
was the reason that data from the read from server got a
1/1/1970 data. And when a user decided to upload that data
to the server again, we ended up with 2 copies of the
GPS fix. One with correct data (as originally saved), and
one new with the bogus date.
In order to het rid of those weird 1/1/1970 GPS fixes, users
will have to remove them by hand.
Fixes: #567
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
To access a QMap<> entry, the value() function is used with a sentinel
as default value. If the sentinel is returned, the code assumes that
the searched for entry doesn't exist.
Make this code more idiomatic by using an iterator and testing for
end().
This fixes a compiler warning, because only one of the elements of
the sentinel was initialized, but the remaining elements were
copied. Harmless, because the code would exit early if it found
the sentinel. Still not nice.
While redoing this function, the entry-not-found message was improved
(adding of function name, space between massage and timestamp) and
elevated from debug to warning level.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
See 2182167b53. Keep the dupicated code in sync.
Originally-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
See commit 6f42ab46da. Unfortunately, this code is duplicated
(and an obvious candidate for code cleanup). So replicate the mentioned
commit here. In fact, the mentioned issue #666 talkes about the mobile
app, and the fix was only done for the desktop.
Originally-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
In certain places the '(int)' cast is used, while in other the
llrint() or lrint() functions. Make the conversation from degrees
in the 'double' form to the 'int' degrees_t consistent using lrint().
lrint() is the function which should give the best results,
because it accepts a 'double' and results in a 'long'
even if degrees_t is 'int'. If the truncation from 'long' to 'int'
is discarding some of the precision then the next step
would be to turn degrees_t into a 64bit signed integer type.
Possible fix for #625.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Calculating dive.when + dive.duration doesn't always give the correct
endtime of a dive especially when a dive has surface interval(s) in
the middle.
Using the helper function dive_endtime() fixes this issue.
Signed-off-by: Stefan Fuchs <sfuchs@gmx.de>
Independ of the settings, the threshold to reset the GPS data was
hard coded to 5 minutes. Now, honour the entered (and updated during
a session) time to refresh the GPS data in the location service.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
If we don't have a GPS service userid in the preferences and the GpsLocation class
isn't instantiated, this would cause a crash.
Fixes#367
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Wfloat-conversion enabled for C++ part of the code
Fix warnings raised by the flag using lrint
Original issue reported on the mailing list:
The ascent/descent rates are sometimes not what is expected.
E.g. setting the ascent rate to 10m/min results in an actual
ascent rate of 9m/min.
This is due to truncating the ascent rate preference,
then effectively rounding up the time to reach each stop to 2s intervals.
The result being that setting the ascent rate to 10m/min
results in 20s to ascend 3m (9m/min), when it should be exactly 18s.
Reported-by: John Smith <noseygit@hotmail.com>
Reported-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Jeremie Guichard <djebrest@gmail.com>
Using gcc option "-Wfloat-conversion" is useful to catch
potential conversion errors (where lrint should be used).
rint returns double and still raises the same warning,
this is why this change updates all rint calls to lrint.
In few places, where input type is a float, corresponding
lrinf is used.
Signed-off-by: Jeremie Guichard <djebrest@gmail.com>
Subsurface uses "local time" which in particular means we never
display time zone information to the user. The user (and our file
format) only sees times like 5pm or 17:00. A better name than
local time (which could mean "local at the dive spot) would
be "watch time", the time displayed by the diver's watch when
she entered the water.
Internally, we store times as time_t, seconds since Jan 1 1970 0:00
UTC. Our convention for conversion between 5pm and time_t as always
been to treat 5pm as if it were UTC.
Then confusion arose since Qt's QDateTime (which is tied to UI elements
like QTimeEdit and similar) is time zone aware and by default assumes
the system time zone. So when we set a QDateTime to 5pm and then later
convert it to time_t we have to take care about the difference between
UTC and the system time zone.
This patch unifies our solution to this problem: With it, we set all
QDateTime's time zone to UTC. This means we don't have to correct for
a time zone anymore when converting to time_t (note, however, the
signedness issue: Qt's idea of time_t is broken since it assumes it
to be unsigned thus not allowing for dates before 1970. Better use the
millisecont variants).
We only need to be careful about time zones when using the current time.
With this convention, when assigning the current time to a QDateTime, we
need to shift for the time zone since its value in UTC should actually be
the watch time of the user who is most likely used to the system time zone.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Qt 5.6.0 is broken when it comes to using CoreLocationService on iOS.
It doesn't even check if the location service is enabled. My patches fix
that and make Qt set an error code right after service creation. Having
the service creation fail is actually the wrong thing to do because then
Qt switches over to GeoClue and that really isn't helpful for our needs
here.
Additionally, Qt 5.6.0 without my patches doesn't follow the REQUIRED
flow of using the location service as it does not check the access
permissions before accessing the GPS service - without doing so the
GPS service will not run in the background.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the GPS source returns an error that could be an indication that the
user hasn't given us permission to use it, so switch our status to NOGPS.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Initially we don't know if we have a source. After that we may think
that we have one, or not have one (but that can actually change while
the program is running if the user, for example, turns the source off
or switches to airplane mode).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I couldn't figure out how to break this down into small, useful commits.
Part of the problem is that I kept going while working on this and as you
can see from looking at the commit, diff tries so hard to find small code
fragments that moved around, that the diff overall becomes quite
unreadable and it seemed impossible to recreate the sequence of steps
after the fact.
It all started with adding the parsing for the GPS coordinates. But while
testing that code I found several issues with the rest of the function.
Most importantly it seemed ridiculous that we carefully tried to match the
texts that the DiveObjectHelper would create for the various fields,
instead of just using the DiveObjectHelper to do just that. And once I had
converted that I once again realized just how long and hard to understand
that function was getting and decided to break out some of the more
complex parts into their own helper functions.
But of course all this didn't happen in this logical, structured, ordered
way. Instead I did all of these things at the same time, testing,
rearranging, etc.
So in the end I went with one BIG commit that does all of this in one fell
swoop.
This adds four helper functions to deal with start time/date, duration,
location and gps coordinates, and depth of the dive.
To avoid mistakes when dealing with the GPS coordinates, there's another
helper to encapsulate the creation of the dive site and we switched to a
current GPS location.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Having subsurface-core as a directory name really messes with
autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an
autocomplete conflict and also was inconsistent with the desktop-widget
name for the directory containing the "other" UI.
And while cleaning up the resulting change in the path name for include
files, I decided to clean up those even more to make them consistent
overall.
This could have been handled in more commits, but since this requires a
make clean before the build, it seemed more sensible to do it all in one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2016-04-04 22:33:58 -07:00
Renamed from subsurface-core/gpslocation.cpp (Browse further)
