Up to now, we passed a "shiftPressed" flag to the individual
selection functions. To be more general replace by a struct
with "shift" and "ctrl" flags.
While doing this:
1) Move the struct into a new statsselection file for better
encapsulation.
2) Change shift to control in the scatter series, since individual
selection of items is usually done with control, not shift.
Shift usually means "select range".
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Placing labels at half-integer values gives horrible
rendering artifacts. Therefore, always round to integer
values. The easiest way to do this is right before setting
the position. Introduce a helper function to round QPointF
in such scenarios.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Render the confidence area and the regression line into a pixmap
and show that using a QSGNode.
It is unclear whether it is preferred to do it this way or to
triangulate the confidence area into triangles to be drawn by
the shader.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Slowly converting the QGraphicsScene items to QSGNodes to
avoid full replot of the scene.
This adds a new abstraction for line-nodes. Since the render()
function here is fundamentally different from the pixmap-nodes
we had so far, this has to be made virtual.
Also, move the quartile markers to their own source file,
since the StatsView source file is quite huge already.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In order not to waste CPU by constantly rerendering the chart,
we must use these weird OpenGL QSGNode things. The interface
is appallingly low-level and unfriendly.
As a first test, try to convert the legend. Create a wrapper
class that represents a rectangular item with a texture
and that will certainly need some (lots of) optimization.
Make sure that all low-level QSG-objects are only accessed
in the rendering thread. This means that the wrapper has
to maintain a notion of "dirtiness" of the state. I.e.
which part of the QSG-objects have to be modified.
From the low-level wrapper derive a class that draws a rounded
rectangle for every resize. The child class of that must then
paint on the rectangle after every resize.
That looks all not very fortunate, but it displays a
legend and will make it possible to move the legend
without and drawing operations, only shifting around
an OpenGL surface.
The render thread goes through all chart-items and
rerenders them if dirty. Currently, on deletion
of these items, this list is not reset. I.e. currently
it is not supported to remove individual items.
Only the full scene can be cleared!
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
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>
