This way the menu items describe what happens when you tap on that menu
item. That seems more consistent and intuitive.
See #1204
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When the slot pageStack.onCurrentItemChanged() is reached
make sure that the stackView becomes non-interactive.
This prevents swiping left on the map to "go back".
Also, always reload the map markers when the map becomes visible.
This is not optimal and instead something in the lines of:
DiveList.model.onChanged()
is a much better solution.
Ideally the map reload should happen on dive removal, dive addition,
dive edits and sync from cloud.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
showMap() uses a location to open Google Maps in a browser.
Make showMap() a generic function to push the mapPage on the view
stack.
Update the calls to this function from child widgets and pages.
Also either call mapPage.centerOnLocation()
or mapPage.centerOnDiveSiteUUID() depending if the caller
wants the map to center on a dive site or on map coordinates.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
See also 15cdcdbc6. There, we introduced the wideScreen (set to true)
to evade a (cosmetic) bug in (most likely) Kirigami. The top dive
was partially obscured on the start of the app. And by setting the
wideScreen to true, the application header became of a fixed height.
Numerous changes further in Kirigami, we can now set this property to
false. This results in a correctly displayed divelist at the start of
the app, and *also* an application header that correcly hides itself
when scrolling up, and displays itself again when scrolling down. So,
a behavior that is common to, for example, mobile brouwsers.
This all said. I still believe this is a workround for strange behavior.
In fact, we should not need to set this wideScreen property at all,
and Kirigami should behave correct in all cases (true, false, unset
at our end). It behaves correctly when set to true or false, but
still displays a partially hidden top item in the dive list when
unset.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Also, this got broken after the Kirigami to verion 2.2 in main.qml.
So, set the header background color according to our theme setting.
Notice, that there is a remaining issue here. We could color the
text color in the header, but now, this seems impossible (or I
do not understand how and where to set this).
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This is a long standing issue. I wish to keep up with Kirigami developments
including new versions of their controls, but this is not always easy.
While we upgraded to Kirigmi 2.2 for most of our QML earlier, using this
new version of main.qml breaks numerous stuff. In fact, so much that
we just needed to wait.
With the progress in Kirigmi, it is now possible to upgrade, with still
some issues on our side to be fixed, but this is manageble now.
The main show-stopper was a construct to set our theme colors, for example:
Kirigami.Theme.highlightColor = Qt.binding(...)
This is not posssible any more, as the Kirigami.Theme has made these
readonly on their end.
This commit just removes the assignments to the now readonly theme
items. And the setting of a correct theme color for the action button.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
See e6e1473e6. Exact same commit but here for the
list of divemaster. The careful reader will spot a
small addition to the clearDetailsEdit() QML function.
Two more field are cleared.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This is the first of a set of commits that are (very) similar.
It appeared that a number of more or less static lists, which are
constructed by a loop over all dives in the logbook, were executed
when changing focus to a next dive. For example, the in this
commit addressed list of used dive suits.
What was wrong was that the suitList was linked to a dive. There
is only a need to construct the list of used suits when data is
changed (and obviously, once on startup of the app). Further, it
appeared that a lot of code was duplicated and that we can use
(in this case) the same code from the desktop completionmodels.cpp.
Basically, this commit involves the following changes:
- include completionmodels.cpp in mobile and desktop (so move
it from the desktop only category to the generic category).
- remove double code from DiveObjectHelper.cpp
- Do not differentiate in the init phase and the normal refresh
of the list
- the per dive logic is now only the getting of a previously
constructed list (in init or update of the divelist).
There are no visible changes in the UI, other than a better
performance when scrolling over dive details.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This commit consists of the following 3 parts:
1. There are 2 source files added, adapt our build process
accordingly.
2. Due to a change in icon and kirigami QML prefixes, we need to
adapt for this as well. Changed mobile-resources.qrc for that.
When this would not be changed, the icons will not be found.
3. To further prepare for the future, abandon the iconName
property in favour of the new icon grouped property, which
can have more attributes than only the name. But currently
it is only a syntactic change.
Tested on Android device, and no visible changes.
Signedoff-by: Jan Mulder <jlmulder@xs4all.nl
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>
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>
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>
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>
We need a white path drawn on the dark action button, but a black path
drawn for the main menu.
(looks like a white space change snuck in here)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
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>
Kirigami prevents us from altering the color of the gps icon in the action menu. So let's display an gps fix icon in the lower left corner of the drawer when the location services is running, colored to match the themes primary accent color.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
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>
Addresses: #492
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Had a bit of rebase issue with this one.
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>
Fixes: #490 items 1) and 2).
1) Reference to isBluetooth.leftPadding is removed as the isBooltooth
checkbox is gone.
2) Do not set background color of downloaded dives. The checkbox is used
to denote "selected or not".
In addition, incorrect references to subsurfaceTheme.PrimaryColor (which
does not exist) are replaced by the correct subsurfaceTheme.primaryColor.
Finally, an obvious copy/paste error width: childrenRect.height. that
is supposed to be width: childrenRect.width.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The built in theme in Kirigami has special variables for sertain objects, this sets the correct color for each object to match our themes.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
