This is mainly a cosmetic improvement. The GPS menu stayed
visible, when selecting most of the options. This looks weird,
as the close of the menu is also an indication of the selected
action carried out. So, just close it
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Navigating using the breadcrumb in the header did leave the
dive detail edit (and add) mode in such a way that (for example)
navigation in the dive list was suspended. Obviously, it is
debatable what should be done. Saving the edits/add, or
cancelling them. For now, this commit cancels them
silently. This is the exact same thing that is happening when
the user selects the dive list from the drawer menu.
Fixes: #932
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
See issue #949. In the dive list, dates are shown in short format, and
when we start to edit an existing dive, the date field on the edit
page is shown in sort format. However, when adding a new dive, the
initial date shows up in long (normal) format. This in not only
inconsistent, but also introduces the parsing problem, as described
in the mentioned issue.
This can be fixed by using short formatted dates in all cases in
the mobile app. As the screen real estate is precious on mobile,
this seems the most logical choice.
Fixed: #949
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This commit fixes a very subtle bug. Probably there for ages,
but never noticed. When manually adding a dive, and canceling
the add right away, the divetable was extended by 1 dive (using
the core function add_single_dive), but canceling never removed
that dive (using delete_single_dive). This is corrected here.
Notice that commit ef543da5af claims to fix issue #950.
With this commit, however, that issue can be seen sometimes
again.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
When editing (or adding) a dive, the internal data containing the
attributes on the edit page was not cleared when editing was
finished (in any way, by saving the edit or by cancelling it).
As long as the user only edits existing dives, all this poses
no problem, as at the start of a dive edit, the data is filled
from the dive to be edited. However, when adding a dive, data
coming from previous edits shows up. This not clearing data
also causes the strange effect as written in issue #950: adding
a dive, deleting it, and adding a dive again, added the first
added dive data, without the edit screen being shown.
All this can be solved by clearing the data from the edit when
editing is done.
Fixes: #950
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Trivial fix. Show the message "Turning off automatic
sync to cloud ..." when turning automatic sync to offline. Just
a more logical moment to show this message. Also rephrase the
message "Enable auto sync" to "Auto sync enabled". It shows
a status, and not an action.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Instead use the application-wide instance. Creating a local
object defeats the whole purpose of these objects - nobody
can receive signals in case the settings changed.
No other cases of locally created SettingsObjectWrapper
objects were found.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Set download srceen in a sane state after a previous download
session using this screen. The erroneous behavior was very
similar to the one fixed in commit 7fe9bbe295dcf92. For example,
download some dives, quit the screen, go back, and the bottom
buttons are still selectable.
This commit resets some values when leaving the download screen
(ie. not only swiping it away), so that it looks sane at a next
visit.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Reset the Retry button on exit of the Download from divecomputer
page. So, it it not reset wehen swiping this page away, or
cancelling a running download, but resetting it on accepting
downloaded dives.
As we do not have real error reporting (from download failures),
this all is a little arbitrary. Another "fix" could be, not
changing the button text at all.
Further notice, this is not specific iOS, but also Android.
Fixes: #895
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This fixes an annoying bug. When entering an existing divesite
in the mobile app, always a new divesite (with same name) was
created, resulting in multiple sites on the same gps location.
So, be more carefull in checking and creating a new site.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
While the autocomplete function only works for the first entry
adding multiple comma separated buddies can still be done.
Fixes#608
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
I consider it more natural for example for the GPS menu
to stay open when an action is clicked. So this turns off
the general close but has to trigger it on individual items.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Otherwise the divecomputer has to be in pairing mode
at app start time.
Unfortunately, this leaves less space for the progress message.
My time/qml knowledge does not suffice to move that to the next line
(when moving that out of the RowLayout it overlaps with
the buttons).
Signed-off-by: Robert C. Helling <helling@atdotde.de>
This enable use of current location on Add/Edit
Signed-off-by: Murillo Bernardes <mfbernardes@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The second argument to set_filename() is a boolean, but was given
an empty string. Since an empty string evaluates to true, directly
pass true for clarity.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
on iOS the address we display on Connection is an UUID, not
a physical address.
This change the pattern (on iOS) used to enable bluetooth_mode.
Signed-off-by: Murillo Bernardes <mfbernardes@gmail.com>
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>
Add the capability to select the location name from a list, constructed
from the known dive sites in the logbook.
Fixes: #546
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Upgrade QtQuick to 2.6. Seeing a small artifact in the application
header, lets see what happens when upgrading more includes.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
When first tested this commit, especially the dive list was looking
terrible. However, after including newer SHA's from libkirigami, and
correcting lots of spacing/margin issue, a retest of this commit shows
no strange artifact any more, and the amount of warnings in the log
output is reduced significantly. So now, it appears save to
upgrade.
Notice that main.qml still uses Kirigami 2.0. and is not updated in
this commit. With version 2.2, there is a new way of theming, that
is not (yet) compatible with our current code. Blindly upgrading to
2.2 leads to a almost black dive list, wrong button colors, and
runtime errors in the log, due to the fact the direct setting from
QML Kirigami's Theme colors is not allowed any more.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Make all char * pointers in pref.h const to make it clear that these
strings are not mutable. This meant adding a number of (void *) casts
in calls to free(). Apart from being the right thing to do, this commit
makes the code more consistent, as many of the strings in pref.h were
already const.
While touching core/qthelper.cpp turn three instances of (void*) into
(void *).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Move all the map widget platform agnostic files to the
<subsurface-root>/map-widget folder.
This avoids the confusion about the desktop version of subsurface
using mobile components. The map widget is planned as a shared
component between the mobile and desktop versions.
desktop-widgets/mapwidget[.h/.cpp] still remain as those are specific
to the desktop version.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
QMap::operator[] creates a new default constructed entry in the map
if no entry with the given key exists. While not problematic (since
typically nullptrs are inserted) this is usually not what you want
for read access.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In commit bdf6dc7828, we pulled in some changes from Kirigami.
I checked all the new commits and they seemed just fine, and a
test (on desktop) on both Qt 5.9.1. and 5.9.2 showed no obvious
problems.
However, some time later, working on something else, I compiled
from Android to test, and saw some strange behavior in the dive
list. The topmost dive is partially hidden behind the application
header on startup of the app, but can be pulled down. Not a big
deal, but is does not look right.
After tedious testing, bisecting, etc, I found commit
d0f3941a4d7f4d4c6 in Kirigami (obviosuly, it was not clear from
the start that it was in Kirigami, as I could well have been
some error in Subsurface, or even Qt). Mentioned commit is
trivial, and handles with the wideScreen property of the
application window. With wideScreen = false, the bug is
visible, when true the bug is gone.
This all said. Just set the wideScreen to true, which can
definitely be considered a workaround. I exspect that this
commit can be reverted later on when Kirigami is fixed.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
While testing the mobile app on Qt 5.9.2, I encounted a show stopping
issue. Select a dive in the dive list, go back to the dive list (as
selecting a dive opens the details), now scroll down to a different
dive, and select one. The app starts enumerating (moved smoothly
according to the specs) all the dives between the old and the new
selected dive. So, depending on the distance, this could take forever.
Explicitly: on 5.9.2. only.
From the Qt docs:
highlightFollowsCurrentItem : bool
If this property is true (the default value), the highlight is moved
smoothly to follow the current item. Otherwise, the highlight is not
moved by the view, and any movement must be implemented by the highlight.
End Qt docs.
Setting this property to false solves the issue. Tested on both Qt 5.9.1
and 5.9.2.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The 'isReady' boolean flag is now set to 'true' only
once the Component.onCompleted slot is reached.
The flag is then used as a safe-guard in the
onZoomLevelChanged slot. Calculate the small circle radius
(mapHelper.calculateSmallCircleRadius()) only if 'isReady'
is set to true.
Prevents a crash if the Map widget is not ready, yet a zoom
level is set via the 'zoomLevel' property. The crash happens
because mapHelper.calculateSmallCircleRadius() has a callback
to the Map component to estimate some points and distances of the
small circle.
Reported-by: Stefan Fuchs <sfuchs@gmx.de>
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Commit 344d976593 resulted in the start of Subsurface with a map of
the whole world. The user has to zoom in (assuming the case that the
first selected dive has a position), in evenry session. This is solved
by setting the zoomlevel at startup at the default value. Ok, this
results in a map of central London, UK, when starting Subsurface with
a dive without location, but is this as good as any map.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
A not perfect improvement, but way better IMHO. Prevent the list of
downloaded dives to grow over the buttons at the bottom. Just a simple
change by adding a bottomMargin to the list.
Notice that there is still some overlap, but for now I consider this a
trade-off between the scarce screen real-estate and the wish to present
and much as possible dowloaded dives.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Trip headers spanning more than one line where broken at incorrect
locations in the string. Not exactly sure, but I think this came with
the newest Kirigami SHA, and especially the Label change.
Carefully reading the code for the trip heading shows a "strange"
negative margin. So the margin is on the outside. This margin was
used to split the string, allowing for a small invisible part of
the string to present as trip header.
This is solved by this commit.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This does two main things to the map widget:
- if there are no coordinates, do *not* zoom out to the whole-world
view. Just leave the map alone.
- when zooming out to move to a new dive site, zoom back in to the same
zoom level it was before.
These two changes make it much more pleasant to move between dives,
particularly as you move back-and-forth without losing the zoom level.
NOTE! The zoom level gets reset if you move dives _while_ zooming is
happening, and so moving quickly between dives will still end up losing
the original zoom level, replacing it with a bigger zoom-out that was
active _during_ a previous zoom.
That could be seen as a feature (moving incrementally to an "overview"
zoom when moving quickly between dive sites), but honestly it smells
more like a bug to me. But regardless of that feature/bug, this new
zoom behavior is more pleasant than our older "always reset when
moving".
But it might be a matter of taste, so people should try this out and
comment.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation,org>
Cc: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Again, mostly related to label change. First, the top button was "glued"
to the top of the screen, so added a little margin there. It
appeared that all the other items on the screen (progressbar,
2 button rows, and the downloaded dive list) where not moving down
due to the add of that little top margin. This was solved by
anchor-ing the items together. Finally, the text of a downloaded
dive was on the top of the delegate lines. Not sure where that came
from, but easily solved by centering it explicitly.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
As in a525fff112, also the dive details top data was not nicely positioned
any more due to the deprecated and removed Kirigami.Label.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The new SHA for Kirigami did all kinds of nasty things to our DiveList.
This commit tries to repair most of the damage. Nothing more than
some margins, anchors, and even a font that changed.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Commit 8f6827ab12 brought a new SHA for Kirigami, but that introduces
a very noisy logging of "Kirigami.Label is deprecated. Use
QtQuickControls2.Label instead".
So, thats what done here.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
First, obviously, I could have squashed this small commit into
the previous one, but I explicly decided not to. It shows
the fragility of all this credential processing code, and
the complex flow control troughout the code.
Testing on a brand new install, and immediately going for
a no cloud setup, the PIN screen was shown, instead of an
empty divelist. Looking at this small code change shows why.
In case of a no cloud situation, there is no PIN to verify
(or email and passwd rules checked). So just do not force us
there.
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>
