Android and iOS use qmake, so add the code to the .pro file.
This also removes all remnants of QCharts includes and uses and all the
references to QCharts in our various build systems.
That was a brief but extremely useful detour.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In analogy to "QMLManager", add a "StatsManager" class,
which manages the statistics module on mobile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Factor out code from ProfileWidget's ToolTipItem, but make
the radius of the corners dynamic. Move into backend-shared,
though a new ui-shared might be preferred.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These were declared in pref.h and defined in subsurfacestartup.c.
pref.c didn't even exist. Create it and move preferences-related
structs and functions there.
setup_system_prefs() is left in subsurfacestartup.c, since it
works with environment variables.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This appears to be needed only for Android with Qt 5.15. Which means
that this commit creates odd breakage in case someone were to try to
build for Android with an older Qt version - but given that the current
build process only works with Qt 5.14 or 5.15, I think this is an
acceptable flaw.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since switching to the mobile-models and removing grantlee,
DiveObjectHelper was demoted to a thin wrapper around string
formatting functions. The last user was removed in a previous
commit.
It was never a good idea, given QML's strange memory-management.
Let's remove it.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
With the removal of grantlee, this became pointless glue
code. Call the formatting functions directly.
Since the printing code was the only user of CylinderObjectHelper,
remove the whole thing.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The mobile version of the list used string formatting functions
defined in DiveObjectHelper and declared in mobilelistmodels.h.
Very confusing. Move them to a separate source file where - in
the long run - all the string-formatting functions, which
are scattered all over the place, can be collected.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The places we build things are still rather inconsistent for historic reasons -
this definitely deserves some more cleaning up.
The top level build-ios dir was completely unused, and the build location for
the googlemaps plugin was inconsistent with all of the other build dirs.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since the integrated build no longer seems to work, this creates a separate
Kirigami build using qmake (as I couldn't make Kirigami's cmake build work).
The install target tries to install into the Qt install which may not be
possible with a user account, so this instead uses the built library directly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It appears that the Kirigami shaders aren't bundled with the app. They
should be part of the plugin, but somehow they aren't. This way things
at least 'mostly work'.
We also need the icons. And to make this a bit more structured, move
those resource declarations into the Android part of the qmake file
until we know how all this works out on iOS.
The Android app is still fairly unusable with all kinds of weird font
problems and many other issues, but at least it once again starts.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And don't try to build kirigami in the same qmake run. The inclusion of the
.pri file doesn't appear to lead to a build that works.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
These are the small dots that describe dragable points on
the profile when in the planner. It makes no sense to have
them in desktop's planner-widget code. They belong to the
profile.
Therefore, move the code there and compile on mobile.
Not everything can be compiled on mobile for now, but it
is a start.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The reference via 1160{QT_ARCH} should work, but for some reason it
doesn't. Making it explicit is technically wrong, but at least it
appears to ensure that the shared objects are bundled correctly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
