Most of the time we are adding all the dives, so do this in a single model
operation. This makes the case when adding a single dive (in the undo delete
function) slightly more complicated, but that seems totally worth it for the
speedup in the common case.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
John Van Ostrand reports that when he dives using two cylinders using
sidemounts, the per-cylinder SAC rate display is very misleading.
What happens is that since the two cylinders are used together (but
without a manifold), John is alternating between the two but not
actually adding gas switches in the profile. As a result, the profile
looks like only one cylinder is used, even though clearly the other
cylinder gets breathed down too.
The per-cylinder SAC rate calculations would entirely ignore the
cylinder that didn't have gas switch events to it, and looking at the
info window it would look like John had a truly exceptional SAC rate.
But then in the general statistics panel that actually takes the whole
gas use into account, the very different real SAC rate would show up.
The basic issue is that if we don't have full use information for the
different cylinders, we would account the whole dive to just a partial
set. We did have a special case for this, but that special case only
really worked if the first cylinder truly was the only cylinder used.
This patch makes us see the difference between "only one cylinder was
used, and I can use the overall mean depth for it" and "more than one
cylinder was used, but I don't know what the mean depths might be".
Reported-by: John Van Ostrand <john@vanostrand.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It's good that this is unused, because it does the calculations wrong.
Due to the gas compressibility the gas use calculations should subtract
the gas_volume() values at the differing pressures, not the pressures
themselves.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The fonts on my Nexus 6p are way too big (especially when compared
to the fonts of the same build on an iPhone 6plus that has very
similar screen size). Simply trying to get more data...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A few more fixes for things that broke in commit 7be962bfc2 ("Move
subsurface-core to core and qt-mobile to mobile-widgets").
[Dirk Hohndel: slightly edited and overlap with Linus' patch removed]
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Subsurface-mobile is the name of the app, but not a good title for
the Dive list / Cloud credential page
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As expected, commit 7be962bfc2 ("Move subsurface-core to core and qt-mobile
to mobile-widgets") caused some breakage.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now that gas switch events always have indices into the cylinder table,
start using that to look up the gas mix from the cylinders rather than
from the gas switch event itself. In other words, the cylinder index is
now the primary data for gas switch events.
This means that now as you change the cylinder information, the gas
switch events will automatically update to reflect those changes.
Note that on loading data from the outside (either from a xml file, from
a git/cloud account, or from a dive computer), we may or may not
initially have an index for the gas change event. The external data may
be from an older version of subsurface, or it may be from a
libdivecomputer download that just doesn't give index data at all.
In that case, we will do:
- if there is no index, but there is explicit gas mix information, we
will look up the index based on that gas mix, picking the cylinder
that has the closest mix.
- if there isn't even explicit gas mix data, so we only have the event
value from libdivecomputer, we will turn that value into a gasmix,
and use that to look up the cylinder index as above.
- if no valid cylinder information is available at all, gas switch
events will just be dropped.
When saving the data, we now always save the cylinder index, and the gas
mix associated with that cylinder (that gas mix will be ignored on load,
since the index is the primary, but it makes the event much easier to
read).
It is worth noting we do not modify the libdivecomputer value, even if
the gasmix has changed, so that remains as a record of the original
download.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In commit df4e26c875 ("Start sanitizing gaschange event information")
back about a year and a half ago, I started sanitizing the gas switch
event data, allowing gas switches to be associated with a particular
cylinder index rather than just the gas mix that is switched to.
But that initial step only _allowed_ a gas switch event to be associated
with a particular cylinder, the primary model was still to just specify
the mix.
This finally takes the next step, and *always* associates a gas switch
event with a particular cylinder. Instead of then looking up the
cylinder by trying to match gas mixes at runtime, subsurface now looks
it up when loading the dive initially as part of the dive fixup code.
The switch event still has an a separate gas mix associated with it, but
this patch also starts preparing for entirely relying on the gas mix in
the cylinder itself, by starting to pass in not just the event but also
the dive pointer to the routines that look up gas mix details.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Some of the gas mix cleanups I'm doing are in code that uses const
pointers, and wants to use this.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The gas switch event handling is somewhat fragile, mostly because the
legacy event encoding for gas switches is odd. It's also limited to
whole percentages, unlike our internal gas mix model.
In addition, it also ends up comparing the values to the raw permille
values, which is wrong for air, and wouldn't match our O2_IN_AIR which
is 209 permille (closest approximation to 20.946%).
So handle air separately, since "21" really is a valid oxygen value for
air, and should match 20.9%. And use the proper accessor functions to
get the gasmix values.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Dirk says that divinglog hasn't been doing the linear pressure
interpolation for a long while, so we're doing extra dive fixups that
really aren't needed any more.
Also, the code is actually buggy: it only ever worked on the first
cylinder anyway (because only the first cylinder pressure_delta[] would
be initialized). That was probably perfectly fine in practice, since
it's unlikely that many tech divers used old versions of divinglog
anyway, so the bug per se isn't a reason to remove it - but it is a sign
that the code was a bit hard to read, so let's get rid of it if there is
no reason to maintain it or fix it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Having subsurface-core as a directory name really messes with
autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an
autocomplete conflict and also was inconsistent with the desktop-widget
name for the directory containing the "other" UI.
And while cleaning up the resulting change in the path name for include
files, I decided to clean up those even more to make them consistent
overall.
This could have been handled in more commits, but since this requires a
make clean before the build, it seemed more sensible to do it all in one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This caches the git ID for the dive on load, and avoids building the
dive directory and hashing it on save as long as nothing has invalidated
the git ID cache.
That should make it much faster to write back data to the git
repository, since the dive tree structure and the divecomputer blobs in
particular are the bulk of it (due to all the sample data). It's not
actually the git operations that are all that expensive, it's literally
generating the big blob with all the snprintf() calls for the data.
The git save used to be a fairly expensive with large data sets,
especially noticeable on mobile with much weaker CPU's. This should
speed things up by at least a factor of two.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is useful if you are in an area with slow or spotty network and if
you are fine with just saving to the phone. In order to sync to the cloud
you either have to manually sync via the menu or turn this back on and
hide the application.
The commit also removes the old refresh from the Manage dives menu as the
semantic of that was possibly destructive now that we no longer
immediately save changes to git - those could be thrown away by selecting
refresh before the app had a chance to save them.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
