When zoomed in, the profile position was moved by hovering with
the mouse. What a horrible user experience. This is especially
useless if we want to implement an interactive profile on mobile.
Instead, let the user start the panning with a mouse click. The
code is somewhat nasty, because the position is given as a
real in the [0,1] range, which represents all possible positions
from completely to the left to completely to the right.
This commit also removes the restriction that the planner handles
can only be moved when fully zoomed out. It is not completely
clear what the implications are. Let's see.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The only things in display.h were profile related, so the
split between these two files is not comprehensible.
In fact profile.h includes display.h, because it needs the
struct defined therein. Let's just merge these two files.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In planner and edit mode, the cursor position is indicated using
crosshairs. They broke when changing to absolute scaling.
To fix them, remember the plot-area in the profile scene and
draw the crosshairs only inside this area (not on top of axes).
However, limit the position of the horizontal line to the
actual profile (dont paint inside the partial pressure, etc
graphs). The vertical line is painted above those graphs, so
that a timestamp can be related to partial pressure, tissue
loading, etc.
Also, set the z-value of the crosshairs. It was painted
inconsistently above some and below other chart features.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
All data access is now directly via the plot_info structure
owned by the ProfileScene itself.
Also removes DivePercentageItem::hColumn, which was an
artifact from the DivePlotDataModel.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The profile was using a Qt-model to access its data. This means
routing everything through Qt's QVariants and lead to verbose
code such as
double prev_y = dataModel.index(i-1, vDataColumn).data().toReal();
Instead of storing a data-column and do access via a template,
simply store accessor functions. The code from above now reads as
double prev_y = accessor(data[i-1]);
This should also be distinctly faster for the ns-optimizers among
us.
Only one case was somewhat nasty to convert: The accessors for
the 16 tissues are now generated via a recursive template. Thanks
to C++17's constexpr if, such a template is pleasantly easy
to follow, though.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The old animation was weird: it would reuse the labels
based on the index, not on the value. Thus, with the
new scaling code, sometimes there was no animation at all,
if the value, but not the position changed.
Consider the values instead and let labels appear/disappear.
This makes things slightly more complex.
While changing this code, create our own animation-class.
Thus, we can avoid having the dive axes being QObjects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This function was used to check wether a screen-point
is located on the profile. Bizzarely, this was done by
transforming into local coordinates and checking
min/max value. Simply check the screen coordinates
directly. Moreover, make the function return whether
the point is inside the region, not outside the region,
to make logic more straight forward.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This is a potentially expensive operation (e.g. interpolation of
pressure values), so don't recalculate the plot data for every
redraw.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There was a bunch of conditionally compiled code on mobile
that had special hiding/unhiding rules.
Try to unify that with the desktop code by introducing a
"simplified" flag. This certainly breaks and will have to
be finetuned. In particular, I can't test CCR dives, which
are treated specially on mobile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We were using the QGraphicsScene machinery to zoom into the
plot. This not only zoomed into the dive, but into the whole
thing. In general, one couldn't see the axes anymore.
Instead, adjust the range of the time-axis according to the
zoom-level and position.
Of course, the code isn't adapted to that and the result
is comical. The chart features will have to be fixed
one-by-one. Oh joy.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There were virtual functions to calculate the label colors
based on the value of the label. However, these functions
only returned constant values. Therefore, just set these
in the constructors.
Thuse, a few virtual functions and derived classes can be
removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The ticks were recalculated twice per plotDive() call:
1) When updating the position of the axes in updateChangeLine()
2) After setting the bounds in plotDive() via setBounds()
Remove the first instance. updateChangeLine() is called in
only one place [from plotDive()] and therefore, the recalculation
is always redundant. Moreover, rename the function to setPosition(),
since it doesn't do any animation at all.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The partial-pressure-axis was the only DiveCartesianAxis
child that had its own code to set the bounds. The bounds
of all other axes were set in plotDive().
For consistency, do this here as well. Thus, the whole
class can be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The placement of the axes was done independently of the
plotting, e.g. when settings changed. Presumably,
for performance reasons. However, since the axes may
depend on whether a dive has heart-rate data or not,
this simply is not viable. To make this work, one
would have to remember whether the previous dive
showed the heart-rate, etc. Not worth it - always
reposition the axes. It should not matte performance-
wise.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
For better scalability, we might replace the dive event icons
by SVGs. Since rendering SVGs is potentially very slow, cache
the pixmaps when the scene is generated.
Note: this does not yet do any SVG rendering, only the caching
of pixmaps.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The tissue percentages were realized as 16 independent polygons.
That didn't work at all with the new absolute scaling.
Reimplement the item and blast it onto a pixmap. Not only is
this artifact-free, it also should (hopefully) be quite a bit
more efficient than painting numerous lines.
In contrast to the old code, this does access the plot_info
structure directly instead of using the model. Not so much
for performance reason, but rather to make things more robust:
We have a strongly typed language. Why would we shoehorn data
through the weakly typed QVariant and mess with wierd
index-arithmetics. Makes no sense to me. Qt-model have to
be used for interfacing with Qt. They are terrible for
intra-application data transfer.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Rendering resets the size, which now recalculates the axes.
Therefore, plotDive() must be called. The callers were doing
the opposite: call plotDive() first, then draw().
To make it easier for the callers, present a single interface
that handles these subtleties.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The chart items were laid out in relative terms with respect
to a fixed scene size (100.0, 100.0). This simply does not
cut it when resizing the chart. Why should the axes always
occupy the same fraction of the chart independent of the size.
Moreover, this led to basically unmaintainable code.
Resize the scene according to the viewport and do
absolute placement of the items. This breaks the layout,
but at least now we have a chance to fix things
somewhat reasonably.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The printFontScale is used to scale up fonts (and icons) when
rendering to high-DPI devices. With absolute scaling, this
will also be used to scale the size of different chart
regions, line thickness, etc. Therefore, give it an more
appropriate name. "Device pixel ratio", which is a well
established term, seems to appropriately describe the
concept.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of using the interactive ProfileWidget2, just
use the ProfileScene to render the profile for printing,
export and mobile. One layer (QWidget) less.
This removes all the kludges for handling DPR on mobile.
Thus, the rendering will now be off and have to be fixed
by redoing the scaling code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Setting the profile and grayscale mode of the profile via
functions is from a time when the same profile widget was
used for printing and the UI. It is simpler to set the mode
when constructing the object and not deal with changes.
To prepare for this scenario, take the flag at construction
time. This still keeps the callers as-is. These will be
adapted later.
Logically, then the printFlag also has to be set in
DiveCartesianAxis at construction time.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The cartesian axes use animSpeed to animate changes. Instead
of passing down the value to the respective functions, the
speed was stored in the ProfileScene and the axes would
access it there. Very messy. Let's just pass down the speed.
There still are back-references from the axes to the scene,
notably to place labels "outside" of the scene. Let's try
to remove them later.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This finalizes the split between interactive (ProfileWidget2)
and non-interactive (ProfileScene) parts of the profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Since the ProfileScene does the actual rendering, it needs
access to the "printMode", "isGrayScale" and "fontPrintScale"
variables. Move them down from ProfileView to ProfileScene.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Part of separating the static (for printing, export) and
dynamic (UI) parts of the profile. This is still quite messy
with many direct accesses from the ProfileWidget.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This simply subclasses QGraphicsScene and is used as
a drop-in replacement. The plan is to step-by-step
move rendering functions there until the non-interactive
code can only use the scene and doesn't have to use
the QGraphicsView. This will hopefully remove quite
some conditional code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
