After porting the picture-items to qt-quick, all that was left
of DivePixmapItem was an empty hull. Remove it. The only problem
was that the DiveEventItem is not derived from QObject anymore,
so we have to explicitly add the translation functions with the
Q_DECLARE_TR_FUNCTIONS macro.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was very painful, because I had to implement rearranging the
paint order of the QSGNodes. The resulting code appears quite
brittle. Let's see where that brings us.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To do so, generalize the animation routine.
This seems to expose a QtQuick bug: we get spurious
hover-events when the tooltip item is updated in the
animation. We have to check for that to prevent
en endless loop (until the user moves the mouse out
of the profile window).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Reimplement a feature that was lost when porting the ToolTipOtem
to QtQuick. This is a bit of a longer commit, because the icon
of the event is now drawn explicitly, instead of using HTML.
This encompasses a UI change: the icon is now the icon shown
on the profile and not a general "warning" icon.
This commit also fixes update of the tooltip when panning the
profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The not-yet implemented parts in the qt-quick port were taken over
as comments, so no need to keep these files around.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
So far, the only dragable item was the legend in the statistics
code. On the profile, we will have multiple dragable items.
Therefore, move the code up and make it more general. This
took some reorganization. Now, the size of the ChartItem
is saved in the base class. Also, setPos() became a virtual
function.
The dragable items are kept as an unsorted list.
If there will be many of them, this should be changed to
some sort of sorted list (maybe quadtree?).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Still behaves weirdly when panning the chart.
No support for moving the ToolTipItem.
Doesn't add information on bookmarks under the mouse cursor.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
It would be nice to have a single "any setting changed" signal and
not to have to listen to all of them individually...
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This feels quite a bit slower than the non-QtQuick version. This
makes sense, as there is an additional level of indirection. Instead
of painting directly, we paint into an QImage and turn that into
a QSGTexture.
Ultimately one would think that we should render directly using
QtQuick. Alas, we can't, since that would mean no more printing/
exporting of profiles. How sad.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This breaks all dynamic features, including animations,
zooming tooltips, planner-handles, etc. They will have to be
converted one-by-one to QtQuick, which will be a major pain,
as the ProfileView is destroyed by Qt6 on reparenting.
This means that the view cannot store any persistent state.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Move most of the QtQuick code to its own directory, so that it
can be reused in the future for the chart.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To make the qt-quick code of the statistics module more general,
don't pass the StatsTheme in render calls to ChartItems. Items
that need it, may just store a reference to the theme.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To make the QtQuick code more general, remove the access to the
StatsTheme, which only makes sense for the statistics module.
Store the background color in a separate variable, since that
will be needed by any potential users of the code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We had a pattern where doubles were converted to long with
lrint() and then down-cast to a narrower int type.
Because this is unwieldy, introduce a function encapsulating
this.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Now that we have defined addition and subtraction on unit
classes, let's use them in a few examples.
Yes, some of these are a bit pointless, because they are
of the kind
a.mbar - b.mbar => (a-b).mbar
However, these probably should be further simplified
by storing the result in a unit type.
This commit is mostly a proof-of-concept.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When adding / subtracting unit objects it is completely
irrelevant with respect to which unit the data is stored.
Why should the user know this?
Therefore add addition / subtraction functions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The goal here is to add general addition and scalar multiplication
functions to the unit types.
Thereto, we need a CRTP
(https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern)
base class.
However, this breaks compound initialization, so we have to use
named initializers:
weight_t { 2000 } -> weight_t { .grams = 2000 }
The good thing is that this is exactly how these classes were
supposed to be used: make the unit explicit!
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Declaring everything at the begin of the function is a K&R
disease, that makes code very hard to follow.
Remove the last assignment to gaschange_after since that is
a noop (found by Coverity).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
It wants us to test for end of container when finding elements.
That is of course reasonable in "production" code, but a bit
pointless in the testing code. Oh well.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was quite ominous: a 60-element fixed size table was
passed as argument to plan(). But there was no check for 60
anywhere? Use a dynamic vector instead.
The whole thing is weird, as the depth of the decostop table
doesn't seem to be used.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
I don't get the point of these calls to dp.clear().
The plan is overwritten immediately afterwards anyway.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Allow the initial gas of the dive to be edited through the context menu
in the dive profile, by right-clicking into the profile at the very
start of the dive.
Of course this will likely completely invalidate the decompression
calculation of any actually logged dives, but this is no different to
the addition and modification of gas changes during the dive that is
already possible.
Proposed by @harrydevil in #4291.
Signed-off-by: Michael Keller <github@ike.ch>
Still, mostly useful for me, but this correctly deals with relative path
names for the working directory (and gives a usage message).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Fix a bug introduced in #4245, causing an incorrect dive mode to be
selected when starting the dive planner from a CCR dive.
Signed-off-by: Michael Keller <github@ike.ch>
A reference to a unique_ptr<> was captured by a lambda used
to calculate variations in the background.
This is of course disastrous, because if the caller runs
first it will delete the object. It's a wonder that this
didn't crash regularly!?
The problem is that capturing unique_ptr<>s in lambdas
works, but makes the lambda non-copyable. Sadly, the
QtConcurrent::run() function wants to copy the lambda.
For now, do this by a release/reaquire pair. This is
not exception safe. However, sine Qt doesn't support
exceptions, we can live with that.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Improve the event loop architecture by making it set the divecomputer in
the constructor - using the same loop for multiple dive computers is not
intended to work.
Also change `next()` in `divemode_loop` to `at()` to make the name more
aligned with its function.
Signed-off-by: Michael Keller <github@ike.ch>
Fix an interger overflow warning when parsing setpoints.
@bstoeger: In the end it turned out that this parser was only used in
one place in the planner UI, and it was simplest to switch this to
using `QVariant.toFloat()` in the model itself, which is consistent how
the rest of the input values is parsed and validated.
Signed-off-by: Michael Keller <github@ike.ch>
When merging two dives, if a divesite is chosen that doesn't
have a GPS location, but another divesite has a GPS location,
then the GPS location of the former is set to that of the
latter.
However, that was done outside of the undo system, so that
it is not undone and the frontend is not made aware of the
change.
Fix this. To simplify things, move the code from the undo
machinery to the core.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
