This is a partial revert of commit 99438121c4 ("mobile/dive-edit: use template
components and theme colors")
Clearly the information given in the Qt documentation on how to theme ComboBox
is flat out broken. The trade-off between 'better dark theme' and 'broken user
experience' is fairly easy to make.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I could have sworn that I have fixed this several times in various places,
but apparently (as shown by todays support emails) it's still possible to
setup a mixed case email address. So let's try to solve this problem at
the very top.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In analogy to the timestamp -> QDateTime conversion, create a
common function.
1) For symmetry with the opposite conversion.
2) To remove numerous inconsistencies.
3) To remove use of the deprecated QDateTime::toTime_t() function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Another small step to make the dark theme at least marginally useful.
We now use our template components and add the necessary elements to have
consistent text color.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I noticed that the download from dive computer page looked especially bad
in the dark theme (a user sent us some screenshots for a different reason)
and a quick look at the sources showed that we weren't using our template
label. Switching to that gives us the correct size by default so we can
drop all those explicit font size parameters. And we get the correct color
as used in the theme.
One random whitespace cleanup snuck into this commit. Oh well.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far the user can't edit them, but at least they are now shown as
part of the dive details. Usage of tags varries widely, I've seen
people who use a LOT of tags to classify their dives, so I'm giving
this a complete row by itself.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes better use of the screen real estate, without (IMHO) seeming
too crowded. This is a tough balance to strike.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Our labels all seem to have a lot of empty vertical space around them.
Try to be a bit more conservative with space.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
By default single line text has too much white space around it. This
smaller, denser label works well to more efficiently use screen real
estate, I think.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
To reset the core data structures, the mobile and desktop UIs
were calling into the dive-list models, which then reset the
core data structures, themselves and the unrelated
locationinformation model. The UI code then reset various other
things, such as the TankInformation model or the map. . This was
unsatisfying from a control-flow perspective, as the models should
display the core data, not act on it. Moreover, this meant lots
of intricate intermodule-dependencies.
Thus, straighten up the control flow: give the C core the
possibility to send a "all data reset" event. And do that
in those functions that reset the core data structures.
Let each module react to this event by itself. This removes
inter-module dependencies. For example, the MainWindow now
doesn't have to reset the TankInfoModel or the MapWidget.
Then, to reset the core data structures, let the UI code
simply directly call the respective core functions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
It appears that some misguided compiler / library combinations crash
on &vector[0] for empty vectors. Even though very unfriendly, they are
technically correct, so let's remove these constructs.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Calling qApp->processEvents() in QMLManager::setNotificationText()
caused crashes, because it could lead to the context-menu that
initialized the call being deleted. Something that QML apparently
doesn't like.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
On startup, we showed progress of the population of the fulltext
and listmodels for every 100th dive. This worked by overwriting
the last line if the new line started with '\r'. Since we don't
do that anymore, we can remove this special case.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
If the user switches away from Subsurface-mobile and back while we are
in our initialization phase, that code might run more than once leading
to undesirable results.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The strange enum casts (that apparently we needed in order to have strongly typed
enums in QML) are really ugly and confusing in the code. Since we had this three
times it seemed worth to create a little helper that hides this nonsense.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We know that we have valid credentials, so calling openLocalThenRemote()
makes no sense, worse, it doesn't respect the special case of
transitioning between accounts. That's the whole point of having a
separate loadDivesWithValidCredentials() call.
Once we have transitioned state, we need to record the now current state
as the old state so that future transitions will work.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The noCloud variable contains our desired state, we need to test for the
previous state for this to make sense.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We haven't supported the GPS web service for a long time.
Also, add another message for the log to be able to more easily trace
one error case.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we're using the undo stack for determining the whether there are
unsaved changes, we have to mark the undo stack as clean after save.
This duplicates code from desktop. It is planned to unify this in
the near future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In analogy to desktop, also consider the state of the undo-stack when
testing for unsaved changes. This prevents us from missing changes.
This adds duplicate code, which will be unified in the near future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These appear to be the only cases where we forgot to ensure data is
saved. And pastDiveData is currently not called as the UI to use it has
been removed.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The code was using the pre-editing dive site name, which appears
weird. Not sure if that was on purpose.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
QMLManager::checkLocation() would only return true if the
dive-site itself was changed, not if the dive-site was set
to a different site.
Thus, in some cases edit events could be lost.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Calling saveChangesLocal() seems like the right thing to do, but it
doesn't do anything useful if the dive list hasn't been marked as
changed. The correct helper function to call is changesNeedSaving()
which makes sure we save the changes and update all UI information.
[Berthold: since this removes the last QML caller of saveChangesLocal()
we can make that function private.]
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This way the launch screen is shown significantly shorter on a device,
and instead the user sees our progress notifications.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This test makes no sense on other platforms (and the log file text is
frankly confusing when not running on Android).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We have convinced ourselves that only the main thread will ever trigger
a save operation, therefore the locking is not needed (and it has
recently started to cause user problems where local changes aren't saved
to storage and get lost).
Fixes#2718
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
QML documentation recommends against using the cacheBuffer for longer
lists and doing more testing shows that this really doesn't help at all.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Small optimization that reduces the number of accesses to the underlying
model. Instead of evaluating the isInvalid member eight times per
delegate, we only check it once.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Without this check we'll show the 'Please tap the plus botton...'
notification during app initialization as we are showing the initial set
of messages - which makes no sense.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
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>
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>
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>
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>
