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>
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>
Commit cf8e87545f implemented a way to cancel pin setup,
and this also has effects on an exit from the app after pressing
the android exit. The change button started with clearing the
email and passwd in order to get the credentail page(s) active
again. While this worked ok, it confuses users that exit the
app from the credential pages, resulting in the need to enter
the credentials again after a restart. It appears that clearing
the credential state is sufficient to get the pages active.
Notice that the android exit is still not working (it seems
a no-op), but the interaction with the buttons in the app
preserves the email/passwd.
Reported-by: Willem Ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The old credential status should only be set when changing the
actual credential status using the setCredentialStatus function.
Setting it here is just wrong. It sets the old status to the
current, and than adds the current to the prefences,
obviously, resulting in old = current, which can not be right
and results in a wrong flow of control in the credential state
processing.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This commit tries to implement most of issue #515. It reworks the
one credential page, which its dynamic PIN part, into two pages.
Main driver of selecting one of the two pages is the showPin
boolean. Page 1 contains the email/passwd field (and the
option to use a no cloud setup). Page 2 only contains the PIN
part (and the option to cancel the process).
The Kirigami central button does not seem very handy here. We
need, for example, a cancel, sign-in and register, only register,
etc. buttons, which are not easy to handle in specific icons.
Therefore, normal pushbuttons are chosen to deal with user
interaction, and the Kirigami button is removed from these
pages.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This commit is just a precaution. It makes sure that the old
(aka previous) credential status is correctly set on all changes
of this status.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This is a very subtile bug. Testing/developing on the desktop for mobile,
with a normal logbook in a git repo, resulted in a surprising effect.
When swichting from a cloud account to a NOCLOUD situation, the no cloud
repo was (not always) reset to the NOCLOUD_LOCALSTORAGE, but to the
normal logbook. Resuling in commits in the wrong repo.
This can easily be solved by setting the filename to NOCLOUD_LOCALSTORAGE,
when switching to NOCLOUD mode.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
In case the credential state is NOCLOUD, the saving of credentials
in the preferences was suppressed in case of invalid data in the
email/passwd fields.
There is no reason to check these fields for correct input, as they
are not used in case of NOCLOUD mode. A simple if statement is added.
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>
Makes sure that the CS_NEED_TO_VERIFY status is carried forward
and sets the showPin flag that triggers the 2 different states
in de QML UI.
The new credential UI will have one page for username/passwd,
used for setting up an account or switchting to a different
account, and a second page to enter a PIN only.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
In case the credential status is UNKNOWN, and the cloud username
and password are empty, do not go automatically to NO_CLOUD status.
This is (again) preparation for future work on credential management.
For example, the user entered an email address with a spelling
error, so does not receive a PIN code email. This user needs a
way out, so there needs to be a <cancel> button on the PIN code
screen. And the most logic was of cancelling is emptying the
entered username/passwd and let the user try again.
Without this change, the user immediately gets into the (somewhat)
final NO_CLOUD state, which will result in (very) confused users.
With this change, there is exacly one way (left) to get into a
NO_CLOUD setup: hitting the proper button, so a deliberate user
action.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
It appears that the onCompleted of the StartPage item is triggered
before the onCompleted of the rootItem. This is logical as the
Startpage is a child of the rootItem. And, yes, this does matter.
As the divelist also contains the logic for initial cloud
registration (and is the default page shown in a state where
the cloud credentials are valid (CS_VERIFIED state)), we need to
know the correct credential state at start of the app.
The move of this one line of code makes sure of that, in addition
to setting the credential state from the preferences. Now, the
setupActions function can reference correct credential data.
This is further preparation for a better cloud creation
process from mobile.
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>
When we want to go the NOCLOUD credential state, do not go the
incorrect INCOMPLETE state.
This is the first in a series of unraveling the preference parameter
prefs.cloud_verification_status and the data that is carried around
in the QMLManager::credentialStatus_t.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
In commit e76f527fe5, the scenario of switching between 2 already
VERIFIED cloud accounts was identified, which was working poorly. It
needed a restart of the app to get the new account visible.
Reason for this, was the setting of the credentialStatus to the value
of an undefined (never set) old credentialStatus. This commit makes
sure we have a defined credentialStatus, just before changing it to
the new one.
A really mini step forward, as the behavior is still not perfect. Now,
the user has to select the dive list manually, after entering
credentials of the new clould account.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The PIN (and cloud account creation) is not limited to the
desktop (any more). Correct the string accordingly.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
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>
Move the location services switch to the GPS menu, indicate both with icon and text if the service is active or not.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
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>
Trucate the logfile on open to remove any data from previous sessions.
This confused me very much, as the new logfile started from the
top, leaving old data on the bottom.
Also added system date for easy reference.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Email addresses are checked for a someone useful pattern, passwords are
letters, numbers, and +-_. only. Reject anything else.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
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>
Since saving checks if there are changes, we have to always mark the dive
list as changed before asking for the changes to be saved.
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 makes sure that if the user switches to offline mode they don't get
incorrect notifications that tell them that they are accessing cloud
storage.
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>
There were several logical flaws here. Ugh.
Don't save things if there are no unsaved changes, if we haven't
initialized this repository from the cloud or if we are already saving
things.
Then, once we decide that we should save, first always save to the local
cache and then check if we should save to the cloud and do so if
requested.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Let's not discard our GPS location when editing site name on mobile.
Fixes#1051
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
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>
If the automatic sync is turned off we could be stuck in a state where we
always thought that we were already in the middle of a save.
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>
We first check the sha to see if we want to load at all. But at that
point we already have the repository and the branch and we have synced
with the remote. So when we decide that we need to reload from storage,
we don't need to repeat those steps, instead we can go directly to the
git load.
For that to work we need to pass the repository pointer and the branch
name back to the caller so that we can directly call git_load_dives().
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We first want to save any exiting unsaved changes to the local repository
(and ONLY to the local repository). After that we want to make sure that
we are syncing remotely, fetch the remote and then (possibly after a
merge) push the changes to the remote. In the end we reset the previous
"local git only" preference which we overwrote for this manual forced
sync.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We had a redundant check of the server reply hidden in there, and the
logic which values were set where didn't really make much sense. This
seems clearer to me.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Most of the time we are adding all the dives, so do this in a single model
operation. This makes the case when adding a single dive (in the undo delete
function) slightly more complicated, but that seems totally worth it for the
speedup in the common case.
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>
