remove LocationService from SettingsObjectWrapper and reference qPrefLocationService
update files using SettingsObjectWrapper/LocationService to use qPrefLocationService
this activated qPrefLocationService and removed the similar class from
SettingsObjectWrapper.
Signed-off-by: Jan Iversen <jani@apache.org>
With the new setup we need to know which state we are coming from
when we are saving cylinder related info. When we are adding
a new dive we explicitly should save cylinder data to the first cylinder.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
Same as for cylinder info, we need to make sure that the gasmixes gets saved to the correct cylinder.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
Save the edited cylinder in the correct slot.
Since the cylinder number and the used cylinder number need not be
the same we first need to test if the cylinder are used.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
This displays the used cylinders in a dive so that they can be edited.
Currently limited to 5 as a POC.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
If we don't know the vendor or product, let's not overwrite information
that we may have remembered from the last time the user downloaded from
this dive computer.
Note that this doesn't try to associate a specific cable with the
information used last time. We could be smarter here for people who have
multiple dive computers, but for the most typical user with just one
dive computer, this does seem like a good solution.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We do strip the user friendly name from BT addresses and this mistakenly
mangled 'USB device' to 'device'.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Parse the device string and try to figure out what was plugged in.
In some cases we know exactly which vendor and product was plugged in,
in other cases we only know which vendor it was, in some cases we don't
even know that (if all we see is a generic FTDI cable).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This only works if the USB device contains enough information to do so.
We need to collect more information to understand what information we
get if those get plugged in. Maybe we'll get only the vendor and need to
leave it to the user to set the product (which we can do by passing an
index of -1 for product).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Unless, of course, the user was editing or adding a dive - that would
be annoying to have interrupted (even though, of course, it's the user
plugging in the device which would trigger this in the first place).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And try to guess which one from the device string we get from the Intent.
The function is named to indicate its future use (because once the user
plugs in such a device, we should show the download page).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user plugs in a device on Android we get a device string that
should allow us to figure out which dive computer was plugged in. Make
that string available to the QML UI.
Right now all we do is log it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
add enum to qPref and remove elsewhere
update source core to reference qPref.
the enum cannot be in pref.h because it is to be used in qml and Q_ENUM
need the enum to be defined as part of the class
Signed-off-by: Jan Iversen <jani@apache.org>
Use Q_ENUM instad of Q_ENUMS (which is depreciated) since it does the
meta registration for all Qt platforms.
Q_ENUM require the enum to be defined in the class and cannot refer to
a global class, therefore copied enum to class.
This commit is made to get the release to work, with minimal changes,
this class will be moved to qPref and the double definition solved
Signed-off-by: Jan Iversen <jani@apache.org>
Remove cloud_storage_status from qmlprefs.h.
usage to qPref::
enum cloud_storage_status is not used from C, but only from C++, and
having the same structure defined multiple times is a maintenance
challenge.
Signed-off-by: Jan Iversen <jani@apache.org>
The clipboard fails if we attempt to copy more than 1MB of data. But the
data buffer used is shared between all transactions 'in flight' and we
cannot tell what else is currently using that buffer. Limiting ourselves
to 500k of text for the logfiles seems reasonable and hopefully makes it
more likely that the transaction will succeed (sadly, Qt doesn't tell us
if it failed).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On some devices (e.g., a Sony Xperia phone) the GenericDataLocation is
not app writeable. Instead of just giving app, try a few other default
locations as well (and since all of these are actually string lists,
try all of the options that Qt gives us).
Reasonably, we should only set the libdivecomputer logfile name if we
found a writeable location.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The info text from the download process wasn't rendered correctly.
maximumWidth ended being a recursive reference and as a result the text
would render as very narrow and super-tall field.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Qt 5.11 adds useful warnings when code attempts to use anchors within
Layouts and even tells you how to fix things.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
remove MapWidget entries from mobile-resources.qrc, and
reference map-widget.qrc in Subsurface-mobile.pro for iOS
Signed-off-by: Jan Iversen <jani@apache.org>
This way the user doesn't inadvertantly end up with information from a previous
run of Subsurface-mobile when they copy the logs to the clipboard.
Not sure we should do the same when building for desktop, so right now it's
only when building for a device.
Reported-by: Thomas Fänge <thomas.fange@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is based on something that Anton Ludin sent to the mailing list.
Reading through the code it seemed that there were scenarios in which
DC_vendor and DC_product were not updated correctly. That's one of the
problems of the declarative approach in QML - it can be very hard to
figure out which code is run when in certain situations.
This may help address the issue with FTDI downloads no longer working on
Android.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The asynchronous load seemed to be (at least one of) the culprit(s) of
the banner occasionally not showing up.
Making the font for the cloud ID smaller looks better (and works much
better for long email addresses).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We want to allow people to keep dives they collected without a cloud
account. The code was mostly there, we just got confused about the
existing status because we ran through this twice (no cloud -> unknown
-> verified). This way we explicitly remember this kind of transition.
Fixes#1404
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
That change clearly would have benefited from better code review.
This is a superset of a change proposed by Jan Iversen.
Closes#1406
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For some reason Kirigami.Icon mess up icon display when filename
extension is omitted. Because of this a perfectly good, scalable svg
show up as a low resolution scaled up icon.
Signed-off-by: Murillo Bernardes <mfbernardes@gmail.com>
calls to savePreferences was moved to prefs. in
b8eb348f54, but the corresponding
C++ code was not merged.
Revert call to savePreferences to manager.
Signed-off-by: Jan Iversen <jani@apache.org>
