UI change: the context menu is opened when left-clicking on
the event. This is probably more compatible with mobile UI.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This uses QWidgets and therefore will only compile on desktop.
We'll have to see how to integrate that on mobile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This needed a bit of refactoring of the ChartItem code, because
we have to be signaled on drag start. Currently only one handle
can be selected at a time. This was (implicitly) the case anyway,
as far as I can tell.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Code is mostly based on the "tooltip item". The dragging code was
slightly reworked to be more logical. A "disk item" was added for
the handles.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The code assumed that when adding chart items to lists, prev
and next are initialized to null. Make this more robust.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
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>
