When the user entered a dive site using autocompletion, it
is a known site, of which we might have a GPS location already.
Just fill the known site coordinates.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Before this change, there was only one way to create the local
no cloud repo on the device. The user needed to add at least
one dive to the no cloud account (so that there is something
to save). While this worked in some scenarios, it could also
get things in an inconsistent state: credential status = CS_NOCLOUD
but no local repo. This was a dead end.
In this commit, the creation of the no cloud repo is made more
explicit. When asking for no cloud mode, just create an (empty)
repo for it when it does not yet exist, and otherwise, just
open the existing (possibly empty) repo.
Now, a user can have no cloud repo, next to (any number of)
cloud accounts.
This leaves one functional aspect left: how does a user abandon
the no cloud repo, by merging his data into a true cloud
account. This is code for this, that tries to do this merge in
a smart way. This seems to be broken (too). To be clear: this
is no part of this commit.
Fixes: #667
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This commit implements possible switching BT on and off during a session,
so not needing a restart of the app when the user forgot to switch
it on when starting the app.
For this, the following needed to be done: 1) create a handler that
reacts on local BT device status changes. 2) repopulate the connection
list in the download screen when a BT status change is detected.
Notice the subtile change of the Q_INVOKABLE btEnabled() function
to a Q_PROPERTY. This gives a nice dynamic behaviour when
switching BT on/off with the app open.
Fixes: #556
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
As written in 8d9ad3cfea7e4c0875, the user needs to be able
to exit the PIN entry UI, in case no PIN can be received due
to a wrong email address.
The simplest way seems to just clear the cloud credential data,
and let the user try again. Obviously, we could argue if the
exact previous state of the 1st credentials screen could
be restored, but as it is only 2 simple fields, of which
it is higly likely that the email adress is misspelled (and
the password hidden), it seems overly complex to implement.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Having two different enums around with more or less the same
definition has lead to unclear code. After removing two not needed
states on the mobile end, the remaining step to one enum for the
credential state becomes almost is simple rename operation.
Unfortunately, I do not know a way to embed a plain C enum
from pref.h into the QMLManager object. So after this, there
are still 2 enums around, but now identical.
This commit is not changing any functionality.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
And here, the removal of a second superfluous state from QMLManager.
This is true no-brainer. While this state was set once troughout the
entire mobile code, it was never tested for this state. Testing shows
that it is safe to change to the UNKNOWN state.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This is a no-brainer removal of the VALID_EMAIL state used in QMLManager.
All current usage of this state is "if state is VALID or VALID_EMAIL",
so there is no distinction between the two states.
It is even a little different. The comment suggests "when we can open
a local cloud storage, tied to a cloud account (so explicitly not
the no-cloud status), we have at least a valid email". While this
is formally true, this implies that there is also a cloud account
on the cloud server (ie. the cloud account is in a VERIFIED state).
In other words: currently, there can't exist a valid local storage
that is tied to a valid email adress, without valid cloud account
on the server.
Notice that this touches the discussion on GitHub for commit
e76f527fe5 (pull request #520). Can we implement the creation
of a valid cloud account without data link to the cloud server?
Currently, we need the server to confirm the email address (for
example for uniqueness reasons on server side). Obviously, we could
hack our way out of this, but we have a perfect solution already
in place. Create a no-cloud account, and transfer that later to
a true and valid cloud account.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Add a checkbox to the preferences page to facilitate selective visibility of the developer menu. With the coresponding function in qmlmanager.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
This commit adds the capability to cancel a running download from DC.
The actual cancel is fully handled in the underlying libdivecomputer
code. As the user may be interested in the dives downloaded up to
the moment of cancel, do not just close the download screen (as
it was before this commit). Now, the <quit> button changes to
<cancel> when the download is started, and pressing cancel, only
cancels the download and does not close the download screen, but
presents the so far downloaded data. When no download is running,
the <quit> button just quits the screen as before.
Fixes: #485
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
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>
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>
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>
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>
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>
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>
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>
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>
In order to get autocomplete to work on manual dive add
we apparently need a separate init function.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With offline the default now, we need to force a connection at least once
so that the repos are in sync. And then of course we need to return to the
correct state, regardless on whether this connection succeeded or failed.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is rather simplistic, it just imports the local data into the remote
repository and therefore loses the git history of the local data - but I
wasn't able to make the git merge without shared base commit work, so I
went this much easier to implement route instead.
One thing we need to be careful about is that contacting the remote server
could fail. If we don't manage to merge the dives from cloud server and
local storage, we need to revery to no cloud status in order not to lose
the local data.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This exposes a locationServiceAvailable property to QML and keeps it in
sync with the corresponding state in the GpsLocation widget.
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>
The manager can now directly update the index of the selected dive, and
the UI tells the manager the timestamp of the currently selected dive.
This allows the manager to pick the best possible dive as selected dive
if things change (for example if the dive list gets reloaded because it
changed in cloud storage).
Fixes#1009
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Before it had the next dive still selected.
Fixes#1053
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On Android we can save locally right away, but we don't want to make the user
wait for a network sync. Sadly, on Android currently the saving in the
background doesn't work and the save will run when the user comes back.
Definitely not ideal.
On iOS the situation is different - a save to the local git cache takes
surprisingly long. Must be the shitty file system they use or something.
Because of that we only mark the dive list changed and instead save the next
time the app is not in the foreground (which works on iOS but not on Android -
go figure).
On all the other OSs (I guess that would be desktop builds of
Subsurface-mobile? But there may be other mobile OSs that people might want to
build it on) we save both locally and to the cloud right away.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So when the user taps on the manual cloud sync, we always force access to
the cloud server. Otherwise we only access the cloud server if
git_local_only isn't set.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes the code much cleaner and easier to understand and should allow
us to then switch back to doing at least the local save right after we make
any changes to the data.
This commit also tries to make sure that the accessingCloud status stays
correct and consistent throughout all the various success and error paths.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user is on the credentials page, doesn't change the credentials
but simply taps on save, they now get back to the dive list.
Fixes#1047
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
