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>
The VPM-B model assumes off-gassing only happens during ascent
which for us are that part of the dive where dp->entered is
false. This is wrong for dives with manually entered waypoints
in the ascent, as discussed in
See #601.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
9m/min (or 10m/min) is the ascent rate assumed by Buhlmann and navy tables,
and the default of most other planning software and dive computers.
Setting the default to 9m/min allows the default behaviour to be consistent
with "expected" behaviour, but does not prevent the user from changing the
preference. There is disagreement between some users whether the final ascent
ascent duration should be considered when determining the length of the final
stop. This change does not alter that at all, but at 9m/min, the difference
is <1min.
See #592
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
.github/ISSUE_TEMPLATE.md will be used when the Github users
create new issues.
.github/PULL_REQUEST_TEMPLATE.md will be used when the Github users
create new pull requests.
The markdown supports HTML comments (<!-- comment -->), which
can instruct the Github user how to create a detailed PR or issue
report.
Most big Github projects use such templates and these can help
the collaborators to examine the PRs and ISSUES faster.
Fixes#598
Reviewed-by: Dirk Hohndel <dirk@hohndel.org>
Reviewed-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Most writes to a connected DC are small, typically some
command bytes to get DC in download mode, or to set
some parameter. All this just worked over BLE,
however, sending a full firmware update (on an
OSTC device) failed, as the underlying BLE interface
can only handle small 20 byte BLE packets at once.
So, send max ble->packet_size chuncks at once.
Tested for the following cases (linux desktop with
OSTC3 over BLE):
1) normal download of dive data.
2) read and write settings from configure UI
3) update firmware (from 2.15 to 2.15)
And to my surprise, no flow control credit administration
is required here.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Stupidly, commit 731d9dc9bd ("DC download: tell user when no new dives
were found") was missing the conditional when to show that messages.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a manually created single commit to incorporate the changes in
https://github.com/Subsurface-divelog/subsurface/pull/502Closes#502
[Dirk Hohndel:]
I was able to manually merge that branch but it created a complete mess
out of the tree and brought several dozen commits in a second time, so
I gave up and instead created this single commit.
Signed-off-by: Philippe Massart <philippe@philmassart.net>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This option should have never been there. This is not how
gradient factors are supposed to work. It would only trick
users to use the wrong value..
Signed-off-by: Robert C. Helling <helling@atdotde.de>
MapWidgetHelper::calculateSmallCircleRadius() uses
the second argument (boolean) of QDeclarativeGeoMap::toCoordinate()
and QDeclarativeGeoMap::fromCoordinate(), which isn't supported
in Qt 5.5.x and errors will be thrown on runtime.
This argument usage is redundant for the calculateSmallCircleRadius()
use case.
If the argument is set to "false" it tells the map to avoid
clipping the viewport and always return a valid QPointF/QGeoCoordinate.
Given that calculateSmallCircleRadius() only works with the
map center - i.e it's called like so in MapWidget.qml:
onZoomLevelChanged: mapHelper.calculateSmallCircleRadius(map.center)
The only way for the radius estimation to fail is if the map widget
width is smaller than SMALL_CIRCLE_RADIUS_PX * 2 = 52px, which is not
possible as the MainWindow splitter prevents it.
If the map widget becomes that small it would be hardly usable,
yet no errors should be thrown related to this change.
Tested-by: Stefan Fuchs <sfuchs@gmx.de>
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
While this interface is deprecated, too much in our existing code depends
on being able to create the QLowEnergyController with just the address.
Additionally, createCentral() is new in Qt 5.7 and therefor this broke
builds on Linux distros that are still on 5.6.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For some reason the progress bar on macOS doesn't show the
progress text. This creates a label below the progress bar
and shows the text there instead.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Especially on BT/BLE devices, where there is a longer negotiation
phase at the beginning of the download, this seems more user friendly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The ordering on Mac appears to be random, but after looking through the
various successful logs of BLE downloads, it seems we always wrote to the
ClientCharacteristicConfiguration descriptor. So try to find that one first,
and only grab the first descriptor in the list if we didn't find a
ClientCharacteristicConfiguration descriptor.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Right now this will only work if you scan for your BLE dive computer every
time. Ideally we should simply initiate a scan and look for that address if
it's not found in the hash.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Following on beb0d5703a, the context menu seems to work fine
with a much older QtQuick import - version 2.0.
The 2.7 import is technically a development leftover
and a minimal version should have been considered earlier.
On older Qt setups (e.g. 5.5.x) this might throw a:
'module "QtQuick" version 2.6 is not installed'
Reported-by: Stefan Fuchs <sfuchs@gmx.de>
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Go back to the old startegy of retrieving the correct end of the dive
plot by looking at the plot data instead of looking at dc->duration.
Signed-off-by: Stefan Fuchs <sfuchs@gmx.de>
Meanwhile (after removing marble) it seems to be a good choice to use
latest MXE version with currently Qt 5.9.1.
Signed-off-by: Stefan Fuchs <sfuchs@gmx.de>
Dive IDs are unique but same dive number can appear multiple times within
the same database. This can happen for example when user changes the
"next log number" from his computer.
Signed-off-by: Seppo Takalo <seppo.takalo@iki.fi>
The provided strod_flags(str, 0, 0) should work as a drop in replacement
for atof() but does not care about locales which may cause atof() to fail.
strtod_flags() would allow checking of conversion result, but I did not
change the existing logic. This was just regexp search&replace change
to get rid of atof(). I use flags 0 to get more relaxed conversion.
Fixes#574
Signed-off-by: Seppo Takalo <seppo.takalo@iki.fi>
We only cleared the first sensor data when we created new synthetic plot
info entries, because we only used to have one (well, we had the o2
data, but apparently nobody ever noticed that it didn't get properly
interpolated, probably because people who have CCR dives with o2
pressures are few, and the pressure drops are gradual anyway).
Clear all the pressure data, so that the interpolation code doesn't
think we have some existing real sensor data for the plot info entries
in between proper sample entries.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The XML saving code got the multi-sensor case completely wrong, because
it still had one place where it would always save the first pressure,
rather than the pressure from the right sensor.
This was hidden by the fact that old data would be saved using the
legacy model that only ever used the first sensor slot. Only if you
actually had multiple sensor slots used would the bug trigger.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Consider cylinder used also if the first and last sample pressure differ
enough
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When Linus modified the gas handling code six weeks ago he pointed out
that that had broken the tankbar; with this patch we now simply walk the
gas changes of the displayed dive directly and create the tankbar
rectangles from that information.
See #562
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
