The undo-code uses owning pointers based on std::unique_ptr to
manage lifetime of C-objects. Since these are generally useful,
move them from the undo-code to the core-code. In fact, this
eliminates one instance of code duplication.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The parser API was very annoying, as a number of tables
to-be-filled were passed in as pointers. The goal of this
commit is to collect all these tables in a single struct.
This should make it (more or less) clear what is actually
written into the divelog files.
Moreover, it should now be rather easy to search for
instances, where the global logfile is accessed (and it
turns out that there are many!).
The divelog struct does not contain the tables as substructs,
but only collects pointers. The idea is that the "divelog.h"
file can be included without all the other files describing
the numerous tables.
To make it easier to use from C++ parts of the code, the
struct implements a constructor and a destructor. Sadly,
we can't use smart pointers, since the pointers are accessed
from C code. Therfore the constructor and destructor are
quite complex.
The whole commit is large, but was mostly an automatic
conversion.
One oddity of note: the divelog structure also contains
the "autogroup" flag, since that is saved in the divelog.
This actually fixes a bug: Before, when importing dives
from a different log, the autogroup flag was overwritten.
This was probably not intended and does not happen anymore.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
For reasons of symmetry (there is a is_manually_added_dc()
function), create a make_manually_added_dc() function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This causes UI confusion. Notably we go into edit mode and
reduce the number of samples, leading to loss of information.
If someone really manually adds a dive with more than 50
samples, they should still be able to explicitly open the
dive in the planner.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of using the save file dialog (which creates a horrendous user
experience - and isn't even supported on Android), simply allow the user
to email the file in question to a recipient of their choice, e.g.,
themselves.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This will allow the user of the mobile app to export dive and dive site
data from their mobile device without using the Subsurface cloud.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The export functionality is horridly poorly implemented, and the UDDF export
isn't actually functional on mobile. And why would we support this in the first
place? That's not a reasonable expectation for the mobile app.
So let's just completely remove that and good riddance.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
No reason to keep this as a macro - a function is easier to
read, type safe and easier to debug. Moreover, give it the
more appropriate name "nearly_equal()". After all, it precisely
does NOT check floating points for equality.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We have two different API endpoints. supportEmail() which adds the
default subject, recipient, and message body, and the generic
shareViaEmail() which takes all of these as arguments.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This was added for Android a while ago, but now this works on iOS as well which
is a very welcome addition for the recipient of these support emails (i.e. me).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For some reason the flag to exclude . and .. breaks this functionality.
It works just fine without that flag, so let's just remove it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This allows having 3m depth grid for metric users.
* All original properties ( named diferently ) were renamed to three_m_based_grid everywhere to be consistent.
* Plus other small changes requested during review.
Signed-off-by: Vlad A. <elf128@gmail.com>
Signed-off-by: Vlad A <elf128@gmail.com>
We had various random "free parts of the git info" left-overs from when
we passed down the git repo data ad-hoc. Get rid of it, and replace it
with just doing a 'cleanup_git_info()' that does the final cleanup of it
all.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
That function name was incomprehensible. What did it check? And what
did the return value mean?
So let's rename it to something that actually describes what it does,
and reverse the meaning of the return value while at it.
So now it's called 'remote_repo_uptodate()', and it returns true if the
remote repository branch has the same value as our 'saved_git_id'.
It's still a bit obscure, but at least within the context of the only
user, the code now makes _more_ sense than it used to:
if (remote_repo_uptodate(fileNamePrt.data(), &info)) {
appendTextToLog("Cloud sync shows local cache was current");
but maybe we could come up with even better semantics and naming, and
make it even clearer.
Requested-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We have this nasty habit of randomly passing down all the different
things that we use to look up the local and remote git repository, and
the information associated with it.
Start collecting the data into a 'struct git_info' instead, so that it
is easier to manage, and easier and more logical to just look up
different parts of the puzzle.
This is a fairly mechanical conversion, but has moved all the basic
information collection to the 'is_git_repository()' function. That
function no longer actually opens the repository (so the 'dry_run'
argument is gone, and instead a successful 'is_git_repository()' is
followed by 'opn_git_repository()' if you actually want the old
non-dry_run semantics.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Apparently some people try to manually enter older dives where they don't
have data about the dive time and therefore want to only capture the dive
date.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We would dereference the undoAction before the command infrastructure
was initialized which led to a crash in the mobile app.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When changing the theme to a dark theme, also change the
statistics theme. The code is a mess, because it crashes
when setting the theme right at the beginning. Therefore,
there is a "theme has been set" flag. Also, this directly
accesses the ThemeInterface singleton object. I have no
time to fight QML, sorry.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Global variables are evil. In this case not a problem, since
this is a singleton anyway. However, it is bad style and does
unnecessary thread synchronization.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This way we can have attachment of fairly arbitrary size (which should
be extremely useful for long libdivecomputer logs). This isn't quite as
intuitive as what we did before - the user needs to pick an email app to
share with), but that doesn't seem too bad - and also... this way they
can share logfiles via Dropbox or analyze them in other apps).
If the file share fails for some reason, we fall back to the old method
with passing the combined logs as body to the support message.
As an implementation detail this keeps the correct path for the app log file around
(this was stupidly overwritten before).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The first location we should try is one that allows us to share files.
In theory this should work on every device, but we do have a few
fall-backs, just in case.
This also moves the Android specific include to the top which seems much
more standard.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In general, replace "dive master" by "dive guide".
However, do not change written dive logs for now. On reading,
accept both versions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
With -Wextra, gcc/g++ complains that compound initialization
of weightsystem_t misses the auto_filled parameter. Add it.
For C++ code we might think about writing a constructor. However,
we use two versions: with and without copied string.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
And while doing that, have all the cases where we already include
qthelper.h simply use a define in that header file - but keep the two
other instances of the define where the C++ source don't need qthelper.h
otherwise.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Qt 6 will drop support for QRegExp.
Use QRegularExpression instead.
The exactMatch in getVersion() was rather bogus, given the pattern.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In commit 105b60389c ("mobile: remove GpsLocation reference from qmlmanager") I
was a bit careless with the code removal and unintentionally also removed the
initialization of the progress callback. With this change the updates from the
download process are once again shown on screen in the mobile app.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This tries to make our fingerprinting code work better, by avoiding
using the "deviceid" field that has always been unreliable because we've
calculated it multiple different ways, and even for the same version of
subsurface, it ends up changing in the middle (ie we calculate one value
initially, then re-calculate it when we have a proper serial number
string).
So instead, the fingerprinting code will look up and save the
fingerprint file using purely "stable" information that is available
early during the download:
- the device model name (which is a string with vendor and product name
separated by a space)
- the DC_EVENT_DEVINFO 32-bit 'serial' number (which is not necessarily
a real serial number at all, but hopefully at least a unique number
for the particular product)
but because the model name is not necessarily a good filename (think
slashes and other possibly invalid characters), we hash that model name
and use the resulting hex number in the fingerprint file name.
This way the fingerprint file is unambiguous at load and save time, and
depends purely on libdivecomputer data.
But because we also need to verify that we have the actual _dive_
associated with that fingerprint, we also need to save the final
deviceid and diveid when saving the fingerprint file, so that when we
load it again we can look up the dive and verify that we have it before
we use the fingerprint data.
To do that, the fingerprint file itself contains not just the
fingerprint data from libdivecomputer, but the last 8 bytes of the file
are the (subsurface) deviceid and the diveid of the dive that is
associated with the fingerprint.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Only used in context of acquiring GPS locations with the mobile app, which
we no longer do.
Keep the DiveAndLocation structure around as that's needed by the
ApplyGpsFixes command.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
