The trick is to pick a path that is accessible from other applications.
In theory QStandardPaths::GenericDataLocation should provide that.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
To be shared between C/C++ and QML code in order to show the updates
and potential error messages from libdivecomputer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This code is based on code from Marco Martin from the Kirigami Android
sample app. In order to simplify the QML code the QMLManager function is
there for all OSs, but it's a no-op on anything but Android.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Translate all of them, but also remove some redundant or possibly
misleading messages. These are now seen by users, not just developers
trying to debug the code.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We have unified the debug output to the console and to the App Log, let's
use it consistently everywhere.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The old system of cloud access updates with fake percentages just wasn't
helpful. Even worse, it hid a lot important information from the user.
This should be more useful (but it will require that we localize the
messages sent from the git progress notifications and make them more
'user ready').
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
One Andorid JNI include was missing. And removed the unused ones
from QMLManager.
[Dirk Hohndel: I had added the missing include elsewhere, so this commit
now only has the removal of the unused includes]
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For reasons unknown to me, the DCDeviceData instance was freed way too early,
and used afterwards, obviously resulting in a SIGSEGV. This commit creates
the DCDeviceData as a direct child of the QMLManager instance, ensuring
it does not get freed prematurely.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This shouldn't be part of the UI (qmlmanager), but part of our
overall handling of dive computers and BT devices.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
appendTextToLog prepends the elapsed time which can be useful, so let's
not remove that but instead have it log to qDebug() instead.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a list of paired BT devices to the QMLManager class. In addition,
a very simple implementation is made of getting the paired BT devices on
Linux, so that we can test further processing of selecting the proper
devices, in a mobile-on-desktop situation.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
It is very impolite to force BT on at start of the mobile app. We cannot
know if the user is going to import dives over BT.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
As Qt is not able to pull the pairing data from a device, a lengthy
discovery process is needed to see what devices are paired. On
https://forum.qt.io/topic/46075/solved-bluetooth-list-paired-devices
user s.frings74 does, however, present a solution to this using JNI.
Currently, this code is taken "as is".
Currently, only for Android (so not mobile-on-desktop, or even desktop).
And only generating logging data in the logcat.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The naming scheme of OSTC dive computers doesn't match their product names,
but they all behave the same from a download perspective, so we assume that
any BT device that has a name starting with OSTC is an OSTC 3.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We remember the offered service uuids as we detect the device and then
try the first one - likely this needs to be fixed / tuned to pick the
right one if multiple uuids are offered.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we find something that looks like a known BT dive computer, set
things up so that we can use it later. If multiple dive computers are
found, simply use the first.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far all this does is list all the BT devices that it finds
(and I worry if this will have negative battery implications
on a mobile device), but this should allow us to connect to
a standard BT dive computer (but that will of course require
more code to pick the right device).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Once we re-inserted the dive in the list we aren't done, quite the
contrary - we now need to make sure that we handle any other changes
and mark the dive list as updated.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We need to set the timeSpec after the QDateTime was parsed,
otherwise it gets converted to localtime again.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We already have that for the other three fields where we offer auto
completion (buddy, divemaster, suit).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In order to make sure we don't render the initial profiles with the
wrong scale on devices, we need to seed the device pixel ratio with the
device default and then update it once the window has been created.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For CCR dives we want to display the setpoint and pO2 information,
due to the limited screensize we have to remove the temperature graph or
the view will be to cluttered.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
We were doing the right thing switching from metric to imperial, but in
order to swtich back you had to restart. Now it works both ways.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There is no need to have two variables for the same purpose.
[Dirk Hohndel: changed to keep the two separate functions as otherwise
we no longer parse existing repos successfully]
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This allows the user to enter multiple buddies as a comma separated list,
the "Multiple Buddies" entry is still a special case as we can only populate
the combobox with a single name for each entry.
fixes#168
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
When editing adive in Subsurface-mobile we can only handle one buddy
due to the limitations of the combobox. To prevent loss of data when editing
a dive with more than one buddy we display "Multiple Buddies" in the buddy
field. This creates a special case where no changes are written to the buddy field
unless the user changes buddy for that dive.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds the option to select a cylinder when adding or editing a dive.
Due to limited screen size we restrict the editing to the first cylinder only.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
If we run the backend to verify credentials without waiting for it to
finish, the redirect might happen before we know if the credentials are
invalid, unverified or verified - which will cause us to give the wrong
information to the user.
Yes, this additional wait is annoying, but I can't come up with a better
way to do this and avoid incorrect information. At least the UI isn't hung
while we wait.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
