Instead of not showing a notification until after we are done loading
the data into our models, tell the user that we are about to do that.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Until the app is initialized, we have problems getting the 'floating'
passive notifications to show up and be useful. Instead update the user
by filling a text block on the otherwise empty initial page of the app.
Delay the switch to the dive list until the app is initialized and then
use the passive notifications again. While we are initializing also show
a busy spinner so the user doesn't think the app is hung.
As a side effect of this change, the dive list isn't shown until our
models are initialized. And strangely this causes every single possible
delegate to be instantiated. We can prevent that by not setting the dive
list model until after we are done setting up the model.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This simply passes the text to the existing notification text mechanism.
The call to processEvents() ensures that Qt processes the UI events
after we updated the notification and that the user gets timely updates;
otherwise the UI might look like the app is hanging.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Especially on slower devices with a large dive list the startup time has
become really long. This callback allows us to give the user an idea of
what the app is doing during that time.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When editing the dive site of a dive, the dive-table of the
corresponding dive site was not properly updated by the undo
commands. Try to get this right.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Our builds fail because we are missing pkg-config.
I'm not quite sure if this is triggered by a new dependency or if pkg-config
used to be there and now isn't. Either way, this should hopefully fix things.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I don't know why this is suddenly needed and wasn't before, but hopefully
this fixes the broken builds on GitHub.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In an attempt to reduce the number of global variables, don't use
a local buffer to store the currently loaded git-id. The git-id
itself is still a global variable, which in the future can hopefully
be encapsulated in a "struct File" or similar.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The inconsistent-missing-override warning is annoying as it prevents
us from adding "override" modifiers: It will warn if we do this only
for selected functions. Sadly, this is the default on clang. Therefore,
we disable this warning for quite some time in CMakeLists.txt. For
consistency also do this in the Subsurface-mobile.pro file.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In DivelogsDeWebServices::updateProgress() QProgressBar::setRange()
and QProgressBar::setValue() were passed floats even though they
expect ints. To silence a compiler warning, cast by hand. Use the
lrint() function, since we generally do it this way. However,
it is not clear whether this is necessary here.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was triggered by a change in enabled, but what is really changing is
the visible property. This should work better.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Especially on smaller screens we had issues fitting this on the screen.
And it looks fine on larger screens as well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This was using the myData alias that exists in the dive list but not on
the dive details. This might work (because the models both use the same
underlying base model), but given that we are using the currentItem of
this ListView, I'm guessing that this would just silently fail (maybe
with a warning in the log).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A second tap on the back button will then end add/edit or close the dive
details and get us back to the dive list.
This fixes an issue where tapping on back with the context menu open
would bring you back to the dive list with the context menu still open,
and because then change the text in the context menu as those are
designed differently.
Reported-by: Willem Ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Do this in analogy to other types. However, here we have to convert
from / to QString. We could do this in an even more general way
by using two templat parameters: one for the Qt type, one for the
core type and define conversion functions. However, let's not do
this for now.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Some dive-editing undo commands have trivial setter and getter
functions: they simply read and write a struct dive member.
Autogenerate these in a template to which we pass a pointer
to member as template argument.
For the invalid-flag we have to turn the edit command from int
to bool, since that is how the flag is store in the dive struct.
Sadly, quite a number of the setters do funky things and we
cannot autogenerate them.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Most edit commands derive from a common base class EditBase,
which declares a fieldId() virtual function that has to be
defined by the child classes. This is tedious. For some reason
the C++ makers refuse to allow "virtual member constants".
To make the code somewhat less verbose, create these functions
by a template. Of course, we could introduce the template
parameter directly in the EditBase class. However, that would
mean that the code in this base class is generated for every
single undo command. I'm not sure we want that.
This should als make it somewhat less tedious to create new
edit commands by copy & paste.
We could do the same for the fieldName. However, that is more
complicated for two reasons:
1) For historic reasons(?) C++ doesn't allow for string literals
as template parameters. Therefore, arrays-of-string would have
to be defined, which is not very nice.
2) We would have to make sure that these strings are recognized
by Qt's translation machinery and use the QT_TRANSLATE_NOOP
macro, which makes the whole thing even less attractive.
Maybe later.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The
- mergeLocalRepo()
- openLocalThenRemote()
functions were not invoked from outside QMLManager.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
QMLManager::changesNeedSaving() behaves differently on iOS:
it only saves locally with saveChangesLocal(), whereas all
other OS save to cloud with saveChangesCloud(). Nevertheless,
even for other OS saveChangesLocal() is called even though
that will be called in saveChancesCloud anyway. Therefore,
compile the saveChangesLocal() call in changesNeedSaving
conditionally.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
It is unclear why the subsurface-helper.cpp file was linked with the
tests. In any case, it led to comlicated ifdef-ery, so let's remove
that for now and readd later if the need arises.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
At least in 4.9.3.1258/3.0.1 I was able to reproduce a situation where I
edit one dive, go back to the dive list, then tap on a different dive
and then the keyboard pops up, obscuring a big chunk of the screen.
This tries to make sure the keyboard isn't shown in dive view mode.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There are two places where we try to prevemt unintended app exits.
Once, in the onBackRequested signal handler on the dive list. This was
missing special handling for the situation where one of the drawers was
open.
The second place is the onClosing signal handler in main.qml. Naively I
thought that this was enough to catch all cases where we were about to
exit the app, but apparently an explicit manager.quit() is a bit too
forceful and doesn't get to that signal handler.
With this commit we check for open drawers in both places. Belts and
suspenders, I guess.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
You can already get to the map by either clicking on the location text
or on the left action button. This third way to get there reduces the
available space for the location text, and can cause positioning issues
with very long location texts creating three or more lines of text,
which then overwrites the dateRow below.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The compiler complained that we were passing a float to the
QFont::setPointSize() function, which expects an integer.
Solve this by using the QFont::setPointSizeF() function.
This might introduce a user-visible change, albeit very unlikely:
We now may set the point-size to a non-integer number.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The compiler complains that members were initialized out-of-order.
Even though this is not an issue here it is correct to emit a
warning, since only then it is guaranteed that the objects are
destructed in reverse-order with respect to construction.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Some slots in QMLManager were not called from the outside, some
only directly from C++-code. Make the former private and the latter
public member functions.
The idea here is to document which functions are actually called
from the outside and which are called from QML or connected to
signals.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Arguably easier to read.
By using the qWarning("...") instead of the qWarning() << "..."
version, we can remove the <QDebug> include.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
QMLInterface was initialized in the register_qml_types function.
Therein, it was in an if branch that tested whether the passed-in
engine argument was not NULL. However, on mobile this could never
be NULL. Let's just move the initialization out of that function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The ThemeInterface was initialized and connected to QML in
the register_qml_types() function. However, it is not a
type. Move the initialization to a place where we create the
other global QML objects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There appears to be no reason for two-phase initialization.
Let's keep things simple: let the constructor produce a
functioning object.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
According to the Qt-docs you *may* send the new values in the
NOTIFY signal of Q_PROPERTYs. However, since changes will lead
to a reevaluation of a whole expression, this argument will be
unused. All it does is make the code more verbose and brittle:
What happens if you send the wrong value?
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We have a singleton class ThemeInterface, which means that it
is global and exists only once. It's members are static, i.e.
also global. A message from the department of redundancy department?
In any case, that makes no sense. Let's just make these members
local to the class.
I would even rip out the whole singleton thing, since the object
is not accessed anywhere outside from QML. Let's keep it for now.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
An Android user might reasonably assume that they can use the back button to
close the global or context drawers. So act accordingly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should deal with the rather confusing 'No dive in dive list' shown
while loading and processing the dive list.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
