There may be other paths where we potentially show the wrong status to
the user... but at least with this it times out eventually; there
shouldn't be any single operation that isn't broken down with progress
markers that takes more than 10 seconds, so keeping the notification
around for 30 seconds seems very conservative.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Much as this felt like the prudent thing to do, it makes the UI painful
to use. In bad network conditions, with a large dive log, on a phone,
the save operation can take more than a minute - which is just completely
ludicrous.
So instead we mark the dive list changed when we make changes and wait
for the app to not be in the foreground. Once the OS tells us that we are
hidden (on the desktop that generally means we don't have focus, on a
mobile device it usually does mean that the app is not on the screen), we
check if there are data to be saved and do so.
There is of course a major problem with this logic. If the user switches
away from Subsurface-mobile but comes back fairly quickly (just reacting
to a notification or briefly checking something, changing a song,
something... then the app may still be non-responsive for quite a while.
So we need to do something about the time it takes us to save the git
tree locally, and then figure out if we can move at least some of the
network traffic to another thread.
And we need to make sure the user immediately notices that the app is not
crashed but is actually saving their data. But that's for another commit.
tl;dr: CAREFUL, don't kill Subsurface-mobile before it had time to save
your data or your changes may be gone. In typical use that shouldn't be
an issue, but it is something that we need to tell the user about.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This allows fairly fine grained analysis on what part of loading from
and saving to git we are spending our time. Compute performance and
network speed play a significant role in how all this plays out.
The routine to check if we can reach the cloud server is modified to
send updates every second so we don't hang without any feedback for five
seconds when there is network but we can't reach the cloud server (not
an unlikely scenario in many dive locations with poor network quality)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Once again this requires changes that aren't upstream in Kirigami.
But with this the bread crumbs update when the user swipes from dive
to dive.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This requires changes to Kirigami that aren't upstream, yet. So there's
a chance that this commit will have to be changed or reverted / redone.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If you show the App log and then start "Add dive manually" or "Show GPS
fixes" you get this odd behavior that the page stack returns to the App
log for some reason. A simple workaround is of course to return to the
dive list, first. Not ideal (because there shouldn't be a reason not to
have the All log in the stack as well, but not really a big problem,
either, since the App log is mainly intended for developers.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This looks a little rough, but I think it works well. I'm sure it could
be prettier, though. The next patch will just do the white space cleanup
for the additional indentation level.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Seems that testing if BOOKMARK is empty is a bad idea. We end up not
getting any samples, but the ones containing a bookmark. So we need to
switch the logic to testing if BOOKMARK contains something and do those
tasks first and otherwise grab a regular sample.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Seems that DiveManager does not always return the dive duration in
DIVETIMESEC field. In this case we can try to calculate the duration
from sample count and interval.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems like a useful default action when people are looking at the dive
list (and it's a request from a user to have this as a button instead of just
via the menu).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This requires a change to Kirigami so that a property change (instead of
calling the open() function) can trigger the animation.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This bug admittedly hits almost nobody, but if you had multiple cylinder
pressure sensors on the same cylinder (attached to multiple dive
computers, of course), we would take the beginning pressure from the
first dive computer, and the ending pressure from the last dive
computer.
That came about because we'd just walk all the dive computer samples in
order, and the first time we see a relevant sample and we don't have a
beginning pressure, we'd take that pressure. So the beginning pressure
was from the first dive computer, and once we'd seen a valid beginning
pressure, that would never change.
But as we're walking along, we'd continue to update the ending pressure
from the last relevant sample we see, which means that as we go on to
look at the other dive computers, we'd continue to update the ending
pressure with data from them.
And mixing beginning/ending pressures from two different sensors just
does not make sense.
This changes the logic to be the same for beginning and ending
pressures: we only update it once, with the first relevant sample we
see. But we walk the samples twice: forwards from the beginning to
find the first beginning pressure, and backwards from the end to find
the ending pressure.
That means that as we move on to the second dive computer, we've now
filled in the ending pressure from the first one, and will no longer
update it any more.
NOTE! We don't stop scanning the samples (or the dive computers) just
because we've found a valid pressure value. We'll always walk all the
samples because there might be multiple different cylinders that get
pressure data from different samples (and different dive computers).
We could have some early-out logic when we've filled in all relevant
cylinders, but since this just runs once per dive it's not worth it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
fixup_dive_dc() is called for each dive computer when we add a new dive.
It does various housekeeping functions, cleaning up the sample data, and
fixing up dive details as a result of the sample data.
The function has grown to be a monster over time, and particularly the
central "walk every sample" loop has become an unreadable mess.
And the thing is, this isn't even all that performance-critical: it's
only done once per dive and dc, and there is no reason to have a single
illegible and complex loop.
So split up that loop into several smaller pieces that each will loop
individually over the sample data, and do just one thing. So now we
have separate functions for
- fixing up the depth samples with interpolation
- fixing up dive temperature data
- correcting the cylinder pressure sensor index
- cleaning up the actual sample pressures
Yes, this way we walk the samples multiple times, but the end result is
that the code is much easier to understand. There should be no actual
behavioral differences from this cleanup, except for the fact that since
the code is much more understandable, this cleanup also fixed a bug:
In the temperature fixup, we would fix up the overall dive temperatures
based on the dive computer temperatures. But we would then fix up the
overall dive computer temperature based on the sample temperature
*afterwards*, which wouldn't then be reflected in the overall dive
temperatures.
There was another non-symptomatic bug that became obvious when doing
this cleanup: the code used to calculate a 'depthtime' over the dive
that was never actually used. That's a historical artifact of old code
that had become dead when the average depth calculations were moved to a
function of their own earlier.
This is preparatory for fixing the overall cylinder pressure stats,
which are currently wrong for dives with multiple dive computers: we
currently take the starting cylinder pressure from the *first* dive
computer that has cylinder pressure information, but we take the ending
cylinder pressure from the *last* dive computer with cylinder pressure
information.
This does not fix that bug, but without this cleanup fixing that would
be a nightmare due to the previous complicated "do everything in one
single loop" model.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This just allows the script to be used when you are working locally on
Kirigami to test changes - no point in waiting for a pull from upstream
then. The only goal is to copy the files over.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Make the lines that together form one dive move closer together so the dives
visually stand out more.
(this also includes small white space change, oops)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This merge was a bit more challenging given how far things had diverged,
but I hope I got it mostly right.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way we have one function that correctly ends both modes.
As a positive side effect this fixes a bug where one could exit the
add mode by tapping Dive list in the main menu which would not delete
the partially created dive.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We really have two different cases for merging dives:
(a) downloading a new dive from a dive computer, and merging it with an
existing dive that we had already created using a different dive
computer. This is the "try_to_merge()" case, called from
"process_dives()
(b) merging two different dives into one longer dive. This is the
"merge_two_dives()" case when you explicitly merge dives using the
divelist.
While a lot of the issues are the same, many details differ, and one of
the details is how dive numbering should be handled.
In particular, when you download from a dive computer and merge with an
existing dive, you want too take the *maximum* dive number, because the
dive computer notion of which dive it is may well not match what the
user dive number is.
On the other hand, when you explicitly merge in the dive list, you end
up renumbering not just the dive you are merging, but also all
subsequent dives, since you now have one fewer dives overall. So that
case already has to be handled by the caller.
Now, the simpler "download from dive computer" case was broken by commit
ce3a78efca ("Assign lower number to a merged dive instead of higher
one"). It fixed the numbering for the divelist case, but broke the
download case.
So this commit reverts commit ce3a78efca, and instead extends and
clarifies the dive renumbering that "merge_two_dives()" already did. It
now explicitly renumbers not just the following dives, but also
renumbers the merged dive itself, so now we can go back to the old "take
the bigger dive number" for the core merging, which fixes the download
case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The logic looked so easy, but the preference needs to be hard coded twice
because there are two scenarios:
- new install, make sure we load the password from settings (so it needs
to be hard coded BEFORE we load preferences)
- update where previously for some reason the user stored that they
didn't want to store the password, so we need to also hard code it after
the settings were loaded
Looks odd, but that should do the trick.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This was exactly backwards. If there already are changes we do NOT want to
reload - that would overwrite those changes for no good reason; after all, the
starting point was correct, so why throw the changes away?
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Create small visible separation from the dive trip before. And make the dive
trip header a slightly different color so they stand out between dives.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes it MUCH easier to deal with a lot of dives.
Instead of needing a more complicated model we simply use the meta data that
allows us to create the dive trip sections to hide (make invisible + height 0)
all dives that aren't in the selected trip.
I'll admit that this was much easier than I expected it to be.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
