| Age | Commit message (Collapse) | Author |
|---|
|
The Page object has the following functionality:
- reloadMap(): reload all map markers.
- centerOnDiveSiteUUID(): center the map on a dive site uuid.
- centerOnLocation(): the map on a latitude, longitude in decimal.
- Select a dive list entry based on a marker selected on the map via
diveList.setCurrentDiveListIndex()
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
|
|
Add the setCurrentDiveListIndex() wrapper for:
diveListView.currentIndex = idx
wich also makes it possible to disable the scroll animation when
selecting dive list indexes which are too far apart.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
|
|
Also a developer likes to see a nicely formatted page, so correct
some bugs in margin handling on the log page. There was a strange
multi-line whitespace on the top of the list, and the total width
of the page was (initially) a little smaller than full page, so
showing a small strip of the page left on the pageStack. This
just looks weird. So again, cosmetics only.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
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>
|
|
This worked correctly while compiled against Qt 5.10.0, but after
installing Qt 5.10.1 the behavior was just wrong. And as there
seems no way to color the background of a Kirigami SwipeListItem,
just revert this, and accept the (slightly) inconsistent coloring
of the page (for now).
This reverts commit 6700715b5dc1d314bc73800d8f8ec387d4d20d16.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
Trivial and cosmetics only fix. The width of the rescan button
was forgotten, and this pushed the right margin to the right,
causing the combo menus to overflow the right margin.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
And another one. The SwipeListItem also needs to have a set
background color. Unfortunately, the lines between the
individual SwipeListItem disappeared, so, set the
smallest possible border on these items.
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>
|
|
For some reason, after the update of the main.qml to version 2.2,
all Kirigami Pages and scrollablePages show up plain white.
So now, set a proper background for these pages.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
This is subtle one. With the changing of the theme color, it
appeared that the hover and selected colors in the divelist
where wrong (as in, always blue-ish). This is easily solved
by setting the activeBackgroundColor to our theme color, and
Kirigami does the rest (tint and opaque settings for the
different states a selected dive can be in).
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>
|
|
Just set the fontsize to something sane.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
Trivial removal of 2 unused Kirigami actions. These were leftovers
from the time we had a very different style of cloud account
management.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
Commits fed2c5b6a1 and 572fc4707 erroneously deleted two
aliases. That is corrected here. Yes, QML with only runtime
errors can be a pain.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
As we need to update our new stringlist models on multiple
locations, just refactor them into a new function.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
See also e6e1473e6. The construction of the locationlist
was not the same as the 3 previous lists, and it needs
the inclusion of a new model file (divelocationmodel.cpp)
in the mobile app. In addition, as the mobile app is mainly
interested in a simple stringList (model) to populate a HintsText
field (or maybe later a combobox), this stringlist is added
to the model, to easy interfacing with QML.
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>
|
|
See e6e1473e6. Exact same commit but here for the
list of buddies.
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>
|
|
Remove the global error buffer and pass the error string directly
to the frontend. The frontend is then responsible for accumulating
errors.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
Instead of manually logging errors after each potentially
error-producing function, use the error-callback. The error texts
are accumulated in the QMLManager object for further use.
The text is transported to the QMLManager object via a queued
connection. Thus, errors can be reported from other threads
without having to deal with manual locking.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
QMLManager::tryRetrieveDataFromBackend() was a one-liner calling
void QMLManager::checkCredentialsAndExecute() with a pointer-to-member.
The latter was never called with a different pointer, therefore
fold the latter into the former and remove the indirection.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
Since the timer will be started on first message anyway, we might
just start it at application startup.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
This was probably an oversight - the timer was only shown for very
specific messages. This was change to show the timer for all messages.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
These were assigned the member variables QMLManager::m_cloudPassword
and QMLManager::m_cloudPassword. Use the member variables directly.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
QMLManager was full of redundant getter functions of the type
bool QMLManager::locationServiceAvailable() const
{
return m_locationServiceAvailable;
}
These can be removed changing READ keywords to MEMBER keywords
in the QPROPERTY declarations.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
There are ca. 50 constructs of the kind
same_string(s, "")
to test for empty or null strings. Replace them by the new helper
function empty_string().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
This is a somewhat hacky commit. For a very long time, the delete
from the divelist on mobile crashed. That is, not always for anyone,
but for me almost consistently. This commit tries to solve it.
I found that trying to save the delete immediately after removing
data from the underlying model seemed to cause the crash. Hacking
around, I found that a simple beginResetModel/endResetModel between
the delete of the underlying model data and actual save is
sufficient to solve the crash.
The big question is, why does this all work? I suspect some of race
condition between deleting model data, and giving the QML engine
the opportunity to do its thing.
This is also related to issue #311, but that is not implemented
here.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
This is the only case where C-code sets the current file.
Remove this call for a better separation of C-backend and
C++-frontend parts.
There were four callers of clear_dive_file_data(). Two of them
would call set_filename() anyway. For the remaining two add an
explicit call to set_filename().
This commit fixes a bug introduced in commit b3901aa8f90499ee2a34efdddc2463105afc53f1:
The cloud-online menu entry was still enabled after "closing" the
cloud storage.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
In QMLManager::saveCloudCredentials(), clear_dive_file_data() was
called just before calling openLocalThenRemote(). The latter calls
the former anyway, so remove the former.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
The new SHA mysteriously caused more than 300 extra warnings in the
app log. It was caused by a code change in Kirigami. The way to
suppress it is, in hindsight, after some hours of searching, trivial.
A Kirigami.BasicListItem shall have an icon defined. And as we do
not care about any icon here, just define it empty.
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
|
|
Copyright strings updated.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
|
|
sizeof() is clearly the wrong way to get to the size of that array...
Coverity CID 208297
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
Coverity CID: 208341
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
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>
|
|
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>
|
|
And make sure we don't create a dive site for an empty location string.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
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 ef543da5aff296e 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>
|
|
The last force=false case was removed in commit 96d1cc570e31396039e4970d2bf75d5f00f1e550.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
|
|
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
|
|
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>
|
Lubomir I. Ivanov
Jan Mulder
Berthold Stoeger
Dirk Hohndel
Joakim Bygdell