The usage of the DiveProfileItems has changed (axes, etc. are passed
at construction time). Update a comment accordingly.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The font print scale is now set once on construction and this
function can therefore be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of intializing the text fields and then changing the
font scale via signal-rigmarole, pass down the font-scale
at construction time.
Since the fontPrintScale is only set in print mode, we also
can access it directly instead of testing for printMode.
Since the DiveTextItem is not updated using signals anymore,
the connected flag can be removed.
The commit is larger than I had hoped for, but this makes
things ultimately less brittle.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The constructors of Time- and TemperatureAxis don't do anything.
In reasonable modern C++ we can simply reuse the constructor
of the base class with a "using" directive.
The point here is to simplify followup commits that will
add additional parameters to the constructors of the axes.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was only used internally - there is no point in an
accessor function. It only makes grepping more complicated.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Not having to readjust the scale on-demand will make the
code distinctly simpler. Let's just pass it once.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Thus, we can keep the scale factor constant during existence
of the view. For now, this is simpler than adapting existing
text elements. We might want to make this more flexible later.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The current way of handling the "print scale factor" is
complex: The text fields are added and later resized via
signals. Things could be simplified by just redoing the
chart when changing the scale factor.
Moreover, in the future we will want to adapt the size of the
axes depending on the size of the texts.
As a first step, factor out the creation of the profile-widget.
This can then be used to recreate the profile when changing
the scale factor.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The alternative spelling "visibile" made searching for this
function very annoying. That makes removing it even more
satisfying.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Very annoyingly, to render the profile for printing / export,
the profile still had to be show()n, thus requiring a parent
window.
Analysis of qmlprofile.c showed that this was due to the
transformation matrix not being properly set up on non-show()n
scenes.
Instead, we can simply render via the QGraphicsScene
(circumventing the QGraphicsView).
The code was factored out into the ProfileWidget2::draw()
function. This will hopefully make it easier to change
the size-code of the profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was just a stub to make the setVisible() function a "slot".
Since there are no more signals using it, remove it.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The visibility of the gas lines is updated on every profile-redraw,
which is performed when the preferences changes. No need to have
these signals.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The visibility is set on every redraw, which is called when
the preferences change. No need for these signals.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This one is rich: when changing to profile-mode, the calculated
tissues are set according to the prefs.calcalltissues flag.
The DiveCalculatedTissue::setVisible() function ignores the
parameter and insteads sets the visibility according to the
expression "prefs.calcalltissues && prefs.calcceiling".
This is because the function is also called by signals,
which provide the wrong parameter.
Pass the correct parameter in the first place. Remove the
crazy signals and the overridden setVisible() function,
which ignores its parameter, later.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Currently, setting the visibility of chart features is a mess. It
is done when switching to the profile state and then via signals,
when the preferences are changed.
However, when the preferences are changed the chart is replot anyway.
So let us simply set the visibility on chart replot. Then in
a follow-up commit, the signals can be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The plan is to simplify the visibility-control of non-interactive
chart features. As a first step identify those features that
depend on preferences-flags and factor out the setting of their
visibility into a new function updateVisibility().
This commit effectively only reorders the setting of the
visibility and therefore should have not user-visible effect.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This does the right thing even when removing a nickname by setting it to
an empty string. The oddly named DiveListNotifier handles the need to
redraw the profile when the name changes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is just a quick first implementation - it will need to use the undo
code in the future, but for now this is a reasonable first step.
It's also missing the code to redraw the profile with the updated DC
name.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds the menu item to rename a dive computer (ie create a nickname
for it) when right-clicking on the dive computer name of a dive computer
that has a serial number (indicated by having a non-zero ->deviceid).
It is nonfunctional because it's really just the skeleton code: it needs
the UI to actually ask for a new nickname, and then it needs to actually
do the proper "create_device_node(model,serial,nickname)" to set it (or
remove the nickname if empty).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If the last displayed dive had events, those DiveEventItems had slots connected
that would update those icons if things changed. When closing the dive log and
switching to a different one, those slots were still called and would then access
freed memory (the event structure from that old dive that is long gone by then).
This code explicitly deletes those DiveEventItems which also removes those signal
slot connections.
Fixes#3305
Sugested-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The DiveCalculatedCeiling had a back-pointer to the profileWidget.
This was used for weird control-flow shenanigans, which were
removed in 975c123a30.
Remove this now useless member variable.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The shouldCalcluateMaxTime and shouldCalculateMaxDepth member
variables of ProfileWidget2 are set to false during drag-mode to
avoid strange shrinking of the graph. They always adopt the
same value. Therefore, replace by a single shouldCalculateMax
boolean.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There is a function to format QString with C-format strings. Let's
use it instead of doing a detour via membuffer.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Thus, the membuffer data is automatically freed when going
out of scope - one thing less to worry about.
This fixes one use-after-free bug in uploadDiveLogsDE.cpp
and one extremely questionable practice in divetooltipitem.cpp:
The membuffer was a shared instance across all instances
of the DiveToolTipItem.
Remves unnecessary #include directives in files that didn't
even use membuffer.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There were two function-static variables in ToolTipItem::refresh(),
which is a very scary proposition. Curently, there is only
one ToolTipItem, but this may change on mobile, where there
are multiple profiles at the same time.
Remove this timebomb and make the two objects subobjects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
It appears that this well intended change in commit 52aa7d83b6 ("Increase event
icon size in print mode") actually causes the scaling of the event icons to be
generally wrong. This removes the hard 4* scaling and also adds some debugging
output in verbose mode.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When printing with low DPI, the dive event items become comically
large, because they are not resized like the fonts. Therefore,
scale using the fontPrintScale.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This occurs upon importing dives for example via CSV.
Make sure the profile display is cleared when selecting
such a dive rather than showing a different dive.
Allow editing the profile for such a dive.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
This enum was an artifact from the primordial days of the profile
widget. As far as I can see it was never used.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The ADD state is not used for adding dives since adding dives
was made undoable. Therefore, rename it to EDIT state, since
that is what it is used for.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Clearly, this comment got lost in code reshuffling, as it comments
about ADD and PLAN mode, but is in front of picture declarations.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The code was downcasting the QGraphicsScene to ProfileWidget2,
but then didn't use the result. *shrug*
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The axes of the profile are setup when switching into
the "ProfileState" and also when the preferences are
changed. The same code existed twice for both cases.
Let's factor it out into a single function to avoid
future divergence and confusion.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The DiveEventItem had an internal copy of the event. It passed
that copy to the undo-machinery, which of course didn't work.
Simply keep a pointer to the event. All changes to a dive no
pass via the undo-machinery, which causes a reload of the profile,
so this should be safe.
Reported-by: Willem Ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Firstly, there is no point in supporting DiveEventItems without
model and axis. Secondly, this avoid pointless position-
recalculations.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There is no point in having a dive event without an event.
Let's pass the event at construction time to avoid having
to handle "invalid" events.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This takes an enum of units::LENGTH, therefore declare it as
such. Yes, this is kind of superfluous bike shedding, but since
we have a strongly typed language, let's use it.
On a side note, the enum should probably not be named with
all-caps.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was only used by the child class DepthAxis,
where it was defined separately. An oversight?
In any case, remove the unused member.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The color was misnamed, since it has only been used for the
duration line for quite some time (since 893bea700c to be
exact).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When creating the context menu, a special menu is created for
the dive computer name.
This was checked in a loop, that set a flag and exited early.
This can all be simplified by moving the loop into its own
function. No more flag, less indentation. Overall better.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When creating the context menu on the profile, the code has
to check whether the context menu is activated on the
dive computer name to show a special menu (delete / split
dive computer).
This was done by setting a special property on the item
and then checking for that property on the item that
the menu is invoked on or its parents.
The reason the code didn't simply check the pointer was
probably that DiveTextItem uses multiple inheritance:
It derives from QObject and QGraphicsItem. It has to derive
from QObject first, because (the ridiculously broken) MOC
needs it that way. The object added to the scene is a
QGraphicsItem. Thus, we get a pointer _into_ the DiveTextItem
object.
However, that's all completely unnecessary. We can simply
compare the pointers, as the compiler will understand that
QGraphicsItem is only the second base class of DiveTextItem.
Magic!
Let's remove the cruft and simply compare the pointers.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These became unnecessary along the way. "qthelper.hpp" was
included twice and <QtWidget> was to broad and was replaced
by <QMimeData>.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When printing, the animation speed was set to 0 by the
caller and later reset to the original value. Instead of
modifying global state, set it internally (in the profile-code)
to zero when in print mode.
This is another small step in making the printing independent
from the shown profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When showing the "empty-state", the profile toolbar was
disabled. This was done via a "reverse" signal from the
profile to the MainWindow. Instead control the toolbar
in the MainWindow directly. Break out the plot-dive
functionality into a member function and there test
whether a dive is shown or not.
The signal makes no sense in the context of mobile
or printing.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When switching to the "plan" or "add" (which should rather be
called "edit", by the way) mode of the profile, the "shortcuts"
for copy&paste, undo&redo, etc. are disabled. When switching
to "profile" mode, they are reenabled.
This was done in a most convoluted way:
- The MainWindow calls the set*State() function of the profile.
- The Profile emits [disable|enable]Shortcuts() signals.
- The MainWindow catches these signals and does the enabling
or disabling.
Not only is this very hard to reason about, it is also in
contradiction to the profile being part of the display layer.
Moreover, in editCurrentDive() the MainWindow disabled the
shortcuts itself, so this was all redundant.
For the sake of sanity, let's just move this logic to the
MainWindow, unslotify the [disable|enable]Shortcuts() functions
and make them private.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In planner or profile-edit mode, the plotDive() function takes
the current plan and turns it into a dive profile. Not only
is this a layering violation (the display layer modifying the
dive), it is also fundamentally flawed. The control-flow is
out of control, if you wish. There are numerous reasons why
the profile needs to be replot, many of which do not need
a recalculated dive profile.
Move the code that updates the dive-profile to the
DivePlannerPointsModel. Thus, the profile recalculations
and replots can be pooled. This will break the planner, since
there now might be missing calls to the profile recalculation.
But it already has some positive effects: when removing
multiple points, the profile is only recalculated once.
This will need much more work, but it is a start.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The DivePlannerPointsModel::addStop() function is called by
the profile to add a planner-stop. It is also used internally
to create profiles.
If we ever want to include this in the undo system, we have
to split these into to versions. One will ultimately place
an undo command and update the profile, the other one doesn't.
For now, this makes the external interface simpler, as some
parameters are redundant.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The dive handlers are only updated by signals. This means that
switching into edit-mode has to be done in steps:
1) initialize the DivePointsPlannerModel
2) switch profile mode
3) load dive into DivePointsPlannerModel
2) and 3) cannot be exchanged, or the dive handlers are not
initialized.
To avoid this sandwitching of profile- and model-initialization,
populate the dive handlers when switching the profile mode.
Thus, the profile can be switched into edit/plan mode when
the DivePointsPlannerModel is fully initialized.
This will be important in upcoming commits, when the initialization
of the dive is moved from the profile to the DivePointsPlannerModel.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The DivePlannerPointsModel::createTemporaryPlan() function had
two distinct and independent parts:
1) create the data points.
2) create the dive sample and calculate variations.
The second part was only exectuted if the recalc flag was set.
Out of the two callers, one was explicitly disabling and setting
the recalc flag to avoid the second part.
The much more logical thing is to simply split the function in
two and only call the first part.
To avoid any functional change, the second caller (the profile)
still tests for the recalc flag. However, if it shouldn't replot
a new plan, why calculate it in the first place!? And why does
the display function change the plan at all? This appears all
very ill-thought out and should be changed in due course.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When moving "dive handlers" with the cursor keys, the
profile was replot twice:
- First the recalculation of the planner model was suspended.
- The "stop" was moved.
- This led to a replot by a signal from the planner model.
However, the old profile was shown, since the recalculation
was suspended.
- The recalculation was reenabled.
- The profile war replot, resulting now in the correct profile.
A classical case of bit rot.
Instead, don't suspend calculation in the first place. This
shows the correct profile on the first replot and the second
replot can be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The ItemPos structure describes the position of various chart
elements on the scene. It had two problems:
- The identifiers were starting with an underscore followed
by a capital letter. This is reserved to the compiler.
- The global object was initialized in the ProfileWidget's
constructor. This means that if there are multiple
ProfileWidgets, the structure is reinitialized even though
it is constant.
Remove the underscores (what was the point anyway?) and
initialize the structure in its own constructor. Moreover,
make the object const to drive the point home.
If this ever needs to be variable, each ProfileWidget
should get its own copy of the object.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
So far the profile operated on the global displayed_dive. Instead,
take the dive to be displayed as a parameter to the plotDive()
functions.
This is necessary if we want to have multiple concurrent
profile objects. Think for example for printing or for mobile
where multiple dive objects are active at the same time.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When moving a planner point with the cursor, nothing
is wrong with extending the dive time by stepping
beyond the current maximum. Same for depth.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The code took care to not delete planner-points when no
points are selected. However, it assumed that all selected
objects are planner-points. But then it checked whether
the selected object actually is a planner-point. So which
is it?
Remove the outter check for an empty selection. This makes
things more logical and more robust, should there ever
be other objects that can be selected.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Both loadFromDive() callers were clearing the model before
calling loadFromDive(). Move the clearing into that function
since it makes no sense to load into a non-cleared model.
Apparently this changes the way that no-cylinder dives are
treated and the code in ProfileWidget2::repositionDiveHandlers()
must now explicitly check for that condition.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There must not be two dive planner points at the same time
stamp, as this violates the laws of physics (and internal
assumptions).
The corresponding test was done in the profile code at
two different places with floating point arithmetics.
This is a bad idea, because
1) code duplication
2) danger of rounding issues
Instead, do this in one central point in the planner model
and use integer arithmetics. Simply add a few seconds until
a unique timestamp is obtained.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When moving the handle with the mouse, the old code tried
to be smart about changing the active handle when crossing
handles.
To me this always felt weird and it was inconsistent with
mouse-move. Theregore, simply do nothing special at all. The
user should hopefully get an intiutive grasp of what's going
on when moving one handler across another.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This model is only needed when in plan mode. To enable multiple
profilewidgets at the same time (e.g. for the mobile app or
for printing), make the pointer to DivePlannerPointsModel a
member variable that is initialized at construction time.
Moreover, allow passing null as the DivePlannerPointsModel,
in which case planning will be disabled. This will be useful
for simple printing.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The connection to the DivePointsPlannerModel was done in two
distinct functions: setAddState() and setPlanState(), which
means that these could easily get out-of-sync. Factor this out
into a single function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When reordering the points, the DivePlannerPointsModel would
not emit the appropriate move signals, but simply a data-changed
signal over all elements. This obviously violates Qt's
model/view API, though it is probably harmless. Let's do
the right thing so that the frontend knows that the selected
item changed place.
Also, emit dataChanged only on the actually changed element,
not all elements.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The ProfileWidget2 slots, which reacted to model changes were
broken. They did not add / remove items at the changed positions,
but arbitrarily at the end. Moreover, they assumed that only
a single item was added / removed and thus violated the model/view
API.
This worked because the handles are completely reset after each
operation and the model only ever touched single items.
Nevertheless, this has to be fixed if we ever want finer grained
undo.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of manually deleting them (and the gases). Currently
there is only one point where these are deleted, but if
we implement proper Qt model/view semantics, this makes things
less headachy.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The "in_planner" condition was inadvertently inverted in
c6d78bc134 and therefore the wrong data was used to draw
the line (density instead of SAC). Revert to original.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To remove reliance on global state, pass an "in_planner" argument
to AbstractProfilePolygonItem::replot(). Thus, calls to in_planner()
can be removed.
This is a bit sad, since the in_planner argument is now passed
to numerous replot() reimplementations of classes derived
from AbstractProfilePolygonItem. However, it is only needed
for one, viz. DiveGasPressureItem. Well, perhaps in the future
more features will depend on the planner mode...
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
AbstractProfilePolygonItem::shouldCalculateStuff()'s definition
has been removed some time ago. Therefore, remove its declaration.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To remove reliance on global state, pass an "in_planner" argument
to decoMode(). Thus, calls to in_planner() can be removed.
This is a more-or-less automated change. Ultimately it would
probably be better to pass the current deco-mode to the affected
functions instead of calling decoMode() with an in_planner
parameter.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There was never an icon passed to this function. Therefore,
remove the parameter and the code that depends on it.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The profile must be replotted when the dive mode changes.
Weirdly, this was routed via the dive-information tab
(making it inherently non-mobile compatible). Detect
such a change directly in the profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There was code to create a fake dc in the profile widget in
the case that there are no samples. To my understanding, this
is obsolete, as such fake data is now generated automatically
when adding dives.
If for some reason there really are no samples, quit early
and go into the empty state.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Adds fields to the advanced preferences page to modify GFLow and GFHigh for
the Buhlmann decompression model for calculating ceilings. Updated preferences
code to set the Buhlmann parameters in core/deco.c when the GF prefs are
updated.
Signed-off-by: Doug Junkins <douglas.junkins@gmail.com>
This now actually displays the calculated ceiling in the profile. There is
still an issue where if the user toggles the setting the already cached profiles
aren't recalculated - that's part of a bigger profile cleanup effort.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The profile had a static variable which prevented animation
when first showing the profile. It appears more logical to
don't show the animation when switching from the empty state.
This removes global state, as a function static variable
exists only once, even if there are multiple objects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The DiveHandler shows a context menu where a cylinder can be
chosen. This indirectly accesses the global displayed_dive
variable.
Remove this in a step to make the profile reentrant.
The code was quite ominous: instead of simply generating the
list of cylinders, a global model was reset and then accessed
with Qt's cumbersome model/view API. All this trampling over
global state can be removed by simply making the function
that generates the list globally accessible.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of accessing the global displayed_dive variable
in RulerItem, pass the dive. This is a step in making the
profile reentrant.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of accessing the global displayed_dive variable,
pass the dive to the various profile items. This is a
step in making the profile code reentrant.
This removes the last user of the displayed_dc macro,
which can now be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Don't access the global displayed_dive variable in an effort
to make the profile reentrant.
Note that this still accesses the global dc_number variable,
which will likely have to be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The profile item that shows the ceilings adds a warning event
if the ceiling is violated. This is very unfortunate.
Improve this situation by adding the event up to the function
that calculates the ceiling. This is still not how it should
be - the display layer should not modify the dive that it
displays.
To make this clear, add a comment that details that this
is a contract between planner and display layer: The planner
uses a dive that can be trampled upon by the profile.
Still, this should be solved differently.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The in_planner() function is incompatible with a reentrant
profile, since it accesses a global variable. In
create_plot_info_new() it is essentially redundant, because
there is a planner_ds (ds = deco_state) parameter that
is used only when in the planner. Therefore use that as
the in_planner indicator: when non-null, the profile is
showing a planned dive.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was used to force a replot on preferences changes.
However, the profile now does a replot in such a case
by itself. This can be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
With the same argument as for DivePercentageItem, move access
to live data out of the paint() function. Instead, calculate
colors in replot(), where the other data are calculated.
This is slightly more complicated than in DivePercentageItem,
since there are multiple polygons. Therefore, replace QPolygonF
by a vector of structures contained the position and color
of the data point.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The DivePercentageItem is a polygon-item with a custom paint()
method. Calculation of the polygon is done once in replot(),
but calculation of the corresponding colors is done in every
paint() call. The problem is, we have no control over paint().
It is called whenever Qt feels like. Therefore using live
dive data is a dangerous proposition if we ever want to get
rid of the global displayed_dive.
Do all the calculations in replot(). Store the colors in an
additional array of the same size as the polygon.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The only time the TankItem is replot is when new data is set.
Therefore, replot() can be folded into setData().
The good thing is that setData() is passed the dive to be
plot. So the data can be extracted from there instead of
the global displayed_dive variable.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The code tried to only replot the profile if necessary, notably
when in edit mode or the ceilings are shown.
That seems like pointless premature optimization, which only
complicates things: The profile is replot every time a
"dive handle" is moved, which means that we depend on the
replotting being reasonably fast. Why should it then not
be redrawn if the settings change?
Let's remove this, as it makes control flow easier to reason
about.
This makes the isPlotZoomed member variable redundant. Remove it.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The old mechanism to replot the profile items was to listen
to model-change signals. Then the code checked whether it
actually had to update anything by looking at the changed
model-indices.
However, the crucial replot was always initialized with
emitDataChanged(), which simple invalidated the full model
and therefore shouldCalculateStuff() always returned true.
Since now the replot() is called explicitly, remove the whole
logic and simply rename modelDataChanged() to replot().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of listening to the dive-data-model changed and
axis changed signals, update the profile items explicitly
once per plot() call. This avoids double replotting of the
dive items.
The old code had at least two replots per plot() call:
one after profileYAxis()->setMaximum() and one after
dataModel->emitDataChanged().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
On each profile replot, the gas axis was implicitly reset
by calling "dataModel->emitDataChanged()", which would send
a signal recieved by the axis. To make the code less confusing
and, more importantly, make order of execution deterministic,
explicitly reset the axis.
Rename the function that resets the axis from "settingsChanged"
to "update" to reflect its usage.
Moreover, remove the "setModel()" function and pass the model
to the constructore. Make it a const reference to make clear
that it can't change during the life time of the axis.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This virtual function is not used as the target of a signal
anywhere, which means that it shouldn't be a slot.
Moreover, mark the one place it is overriden as override.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In contrast to most other items, which are cleared in the
setEmptyState() function, the profile items are cleared
indirectly via a signal from the model. Very hard to follow
and indeed, I thought I could just remove the slot.
Do this explicitly instead for deterministic code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When the settings change, the depth axis is redrawn
to reflect metric/imperial units. To check whether the
units changed, the old length unit is saved in a static
variable. This makes no sense and allows for only one
depth axis. Make this a normal member variable that is
initialized in the constructor.
Also remove the settingsChanged() call in the constructor,
since this is a no-op (the depth unit is unchanged).
Contains a whitespace fix.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There is no point in a separate set-axis function if we never
change the axis anyway. Make the axis a const-reference to
show that it can never be changed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Since the initial commit introducing TankItem, there was
a connection that replotted the item if the horizontal axis
sent the sizeChanged() signal. I never managed to create
this signal for the horizontal axis, only for the vertical
axes. Therefore remove this thing. If it turns out that
we need it after all, readd it in a more deterministic
way (i.e. call where it is needed).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This one is extremely obscure: TankItem::setData(), which is
called on every replot, was passed the DivePlotDataModel,
even though it doesn't access that model at all.
Instead, it connect()s to the model to stay informed of changes
to the data. First of all, this should obviously be done
once in the constructor, not on every replot.
But also, the setData() function is called on every replot
one lines before sending the model-changed signal.
Thus, the tankitem was always repainted twice.
Just remove the whole connect() thing and go for a more
deterministic model. Should the tankbar not be repainted
anywhere, add the appropriate calls there.
Accordingly rename the "modelDataChanged" slot to "replot".
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
settingsChanged() is a virtual function, which is called
when the preferences dialog signals changes. In most derived
classes, the function does nothing.
In two classes, DiveProfileItem and DiveCalculatedTissue, it
replots the item respectively changes its visibility.
However, these two flags are *not* controlled by the preferences
dialog. Indeed, the functions are also connected to finer-grained
qPref signals. Therefore, settingsChanged() can be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Collect all the created profile items in a dynamic vector.
This allows us to loop over them when adding them to the
scene, instead of addressing each item individually.
Hopefully, this will also allow for a more deterministic
repaint logic, without relying on signals.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The only thing left that this function did, was setting the Z-value
of the item. This can be done directly on construction.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This function was called after creating the items. It can be
called directly to create the items. Less chance of mixups.
For this to work, the initialization of isGrayscale has to
be moved to the front, because createPPGas sets the color
according to this flag.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of typing out the same arguments again and again,
do the allocation of DiveProfileItems in a templated function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
A few DiveCartesianAxis functions that were pure accessors
were not const. Make them so. Moreover, mark a few overridden
virtual functions as such.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The profile items had a "setModel()" function to set
the DivePlotDataModel post creation. The model is never
changed. It does however mean that the model might be
null in a short period between construction and setting
the model.
To simplify reasoning about this code, set the model
in the constructor. To drive the point home that the
can never change and cannot be null, turn it into a
reference.
Yes, this is gratuitous bike-shedding, but it helps
me analysis the code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The DiveCalculatedCeiling profile-item has a recalc()
function, which calls "dataModel->calculateDecompression()".
This is a questionable reversal of control-flow: The
profile-item should paint the model-data not change it.
The code was supposed to be called under two conditions:
1) The value of the calcceiling3m preferences flag changed.
This code was buggy for two reasons: Firstly, the cached
value was always initialized to false, which means that
sometimes the first call was missed. Secondly, the
settingsChanged() functions was only called when closing
the preferences window, not when changing the flag in the
profile widgets.
2) The datetime of the dive changed. The whole control-flow is
pretty absurd (due to "bit rot"):
- The replan-dive command sends a date-time changed signal.
- The main tab changes the date-time and informs the profile.
- The profile sends a signal to the item.
- The item instructs the model to recalculate the
decompression.
- The model causes the profile to be redrawn.
In any case, the whole thing is moot, because the decompression
is recalculated for *every* profile plot in create_plot_info_new().
Let's remove the code from the DiveCalculatedCeiling profile-item
and the calculateDecompression() function, which is now not
used anymore.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Dirk says rounded corners look better. This now looks a bit
extreme to me and probably the border size should be increased.
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>
If a dive changes, we should simply redraw the profile. This could be
improved by checking for the fields that might impact the profile at
all, but this is definitely a step in the right direction.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Recently (674c20227b), the call to ProfileWidget::clearHandlers()
was moved from PlannerWidgets::replanDive() to ProfileWidget2.
This cause a crash, because the code assumes that the number
of elements in the handles-vector the divepointplanner model
is the same.
Clearing the handles violates this assumption. It turns out
that the clearHandlers() function is broken anyway: it clear
the handles-vector, but not the gases-vector, which should
likewise have the same number of elements. It appears that
the clearHandlers() function is an artifact and it is
mysterious how this has worked so far. Remove.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
On clicking the DivePictureItem "trash" icon, the item would delete
the picture it represents in the currently displayed dive. This needed
an access to the global "displayed_dive" variable, which we want
to get rid of to make the profile more flexible. For example, we
want to render the profile for printing without messing with global
state.
One solution would be to save the dive with every DivePictureItem.
This commit follows a more Qt-ish strategy by handling this via
signals: The close button emits a signal that is recast by the
DivePictureItem and ultimately handled by the ProfileWidget2,
which knows which dive it represents.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These were only calling the corresponding functions in the
base class. So just don't override them..?
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The mainwindow was connecting preferences changes to the profile.
Do this directly in the profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
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>
This function, which removes the handlers from the profile, was called
in setAddState() but not in setPlanState(). In the latter case it was
called explicitly by the caller.
Move the call from the caller into the function. This allows us to
make clearHandlers() private in to the profile widget.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
So far, the PreferencesDialog emitted a settingsChanged signal.
This meant that models that listened to that signal had to
conditionally compile out the code for mobile or the connection
had to be made in MainWindow.
Instead, introduce a global signal that does this and move
the connects to the listeners to remove inter-dependencies.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of using the two different ways Qt supports swap, depending on the Qt
version in use, let's simply use std::swap()
Suggested-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This has been deprecated for years.
The delta() member dealt with the old style mouse wheel that is associated with
a vertical scroll - so we need the y-component.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since dive.c is so huge, split out divecomputer-related functions
into divecomputer.[c|h], sample.[c|h] and extradata.[c|h].
This does not give huge compile time improvements, since
struct dive contains a struct divecomputer and therefore
dive.h has to include divecomputer.h. However, it make things
distinctly more clear.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In an effort to reduce the size of dive.h and dive.c, break out
the event related functions. Moreover event-names were handled
by the profile-code, collect that also in the new source files.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Now, that we have this helper function that should have been
introduced long ago, we can make some more expressions
more idiomatic.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
core/device.h was declaring a number of functions that were related
to divecomputers (dcs): creating a fake dc for manually entered dives
and registering / accessing dc nicknames. On could argue whether
these should be lumped together, but it is what it is.
However, part of that was implemented in C++/Qt code in a separate
core/divecomputer.cpp file. Some function therein where only
accessible to C++ and declared in core/divecomputer.h.
All in all, a big mess. Let's simply combine the files and
conditionally compile the C++-only functions depending on
the __cplusplus define.
Yes, that means turning device.c into device.cpp. A brave soul
might turn the C++/Qt code into C code if they whish later on.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There is a number_of_computers() function which does
the same thing with two exceptions:
1) checks for null-dive
2) returns an unsigned int
Replace calls to count_divecomputers() by calls to number_of_computers().
In one case, the return type makes a different - add a cast to int there.
Ultimately, we should probably change the dc_number to signed int
throughout the code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When plotting the profile in higher resolution for export,
increase the icon size in the same way.
This is commented out for the mobile version as that
uses printMode for profile display.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This new option allows a user to select a new destination tank for an
existing "Gas Change" event. This is useful when Subsurface's heuristics
get tanks wrong after an import from a divecomputer. The use-case arose
from sidemount divers with air-integrated transmitters as well as carrying
a deco tank.
Signed-off-by: Michael Werle <micha@michaelwerle.com>
Since the profile does not listen to DivePictureModel resets anymore,
the pictures weren't cleared when clearing the canvas. Do this
explicitly.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The code is rather complex. Firstly, we have different representations
of pictures throughout the code. Secondly, this tries to do add the
pictures in batches to the divepicture model and that is always rather
tricky.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Even though the functionality is seemingly trivial, this is a bit
invasive, as the code has to be split into two distinct parts:
1) Post undo command
2) React to changes to the divelist
Don't compile that code on mobile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
ProfileWidget2::plotDive() had this weird interface, where passing
in NULL as dive would mean "show current_dive". However, most callers
would already pass in current_dive. Therefore, unify and always pass
in current_dive if the caller wants to draw the current dive.
This allows us to interpret NULL as "show empty profile". Thus,
passing in current_dive when there is no current_dive simply shows
an empty profile. This makes the calling code in
MainWindow::selectionChanged() simpler.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Firstly, the parameter appears conceptually wrong, as replot suggests
that the currently shown dive is replot. Secondly, the only caller that
passed a parameter was passing in current_dive, which is just what happens
if one doesn't pass a parameter. Therefore, change that caller (call
plotDive directly) and remove the parameter.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When populating the events of a profile, a pointer to the current
gasmix was passed around to properly calculate isobaric_counterdiffusion.
The DiveEventItem::setupToolTipString() function updated this gasmix
when processing gas change events.
I inadvertently broke the code when replacing gasmix-pointers by
values. We could of course simply revert this part of the commit.
However, the data flow was horrible anyway: for example is supposed
that the setup functions were called in the correct order (i.e.
DiveEventItem::setupToolTipString() is called after all other
functions using the gasmix). Not exactly easy to follow.
Therefore, keep passing around the gasmix as value to make it clear
that the functions don't modify it. Keep the gasmix up-to-date at
the caller's site in ProfileWidget2::plotDive().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These two Q_ASSERTs made no sense - their expression (a string
literal) always evaluated to true. A qWarning() was intended here.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The profile data was not properly cleared when not showing a
dive.
Fixes#2787
Reported-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Some profilewidget classes hat protected members which can
be made private as there is no subclassing.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There were a number of protected member functions in ProfileWidget2.
However no class subclassed ProfileWidget2, so this appears to have
been an artifact. Therefore, make these functions private.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This is a bit hairy as - in theory - one gas switch can remove
other gas switch(es) at the same timestamp. However, I did not
find a way to test it. Moreover, it is not clear whether the
dive-tabs are properly updated on undo/redo.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was a trivial copy & past of the event-adding undo command
with a switch of the undo() and redo() actions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There is a slight complexity here owing to the fact that the profile
works on a copy of the current dive: We get a copy of the event and
have to search for the original event in the current dive. This
could be done in the undo command. Nevertheless, here we do it in
the profile so that when in the future the profile can work on a
non-copied dive we can simply remove this function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Since pointers to divecomputers may not be stable, the undo
commands take a dive + a divecomputer number. Update the
SetpointDialog accordingly.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We have too many global objects. There is no reason why this dialog
should be a persistent global object.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This basically copies the bookmark code, with the addition that
the dive mode is recorded in the text of the undo command.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a DiveListNotifer::eventsChanged signal, which is emitted when
the events changed. This is very coarse, at it doesn't differentiate
between signal addition / editing / deletion. We might want to
be finer in the future.
Catch the signal in the profile-widget to replot the dive if this
is the currently displayed dive. Reuse the cylindersChanged() slot,
but rename it to the now more appropriate profileChanged().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Create a new translation unit for event-related undo commands.
Create a base class of commands that add events and one subclass
that adds a bookmark event.
Use this command in the profile-widget.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Since we removed the setData() calls of the QActions in
ProfileWidget2::contextMenuEvent(), we don't have to manually
generate the QActions. We can simply use the convenience
overload of addAction() that takes a string and a functional.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The removeEvent(), hideEvents() and editName() actions need
the DiveEventItem they are applied to. This was transported
via QAction's user-data, which means casting to void and
back.
By using lambdas instead, this can be made perfectly type-safe:
First we are 100% sure that we have a DiveEventItem because
we check the result of a dynamic_cast<>. Then we can pass
it to the even using its proper type.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This is not such a big gain as for addDivemodeSwitch(), but still
simpler. Therefore, let's do it for consistency.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The unhideEvents context menu action was fed with the click-position.
However, that was not used. Therefore, remove it.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The data was transported via the action in a most complicated way:
The text was backtranslated. Simply use a lambda - perhaps hard to
read, but much simpler to follow and less brittle.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In two cases we were passing the magic value 8 instead of the
symbolic SAMPLE_EVENT_BOOKMARK. Use the symbolic version instead.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In the profile, catch cylinder-editing signals and redraw the
profile if the currently displayed dive has changed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The compiler complains that members were initialized out-of-order.
Even though this is not an issue here it is correct to emit a
warning, since only then it is guaranteed that the objects are
destructed in reverse-order with respect to construction.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
If the user is scaling out again we need to make sure that our offsets
are adjusted so that we always show a subset of the profile and not
'empty space' outside of it. Instead of reimplementing the offset logic,
let's just trigger another paint() call.
This requires a trampoline function because of different signal and slot
signatures.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When zooming and panning the profile, make sure we always show a subset
of the profile and don't end up showing the empty space outside of the
profile.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Grammar-nazi ran
git grep -l 'indexes' | xargs sed -i '' -e 's/indexes/indices/g'
to prevent future wincing when reading the source code.
Unfortunatly, Qt itself is infected as in
QModelIndexList QItemSelection::indexes() const
Signed-off-by: Robert C. Helling <helling@atdotde.de>
This will seem too small to many - it's pushing it, but it leads to a
significantly less cluttered profile, and we now have the zoom capability for
readability.
I think this is a nice improvement.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The gas change context menu was filled from the CylindersModel.
This means that even before saving new cylinders, the user could
add a gas change event to these cylinders.
Instead, fill from the current dive.
Fixes#2552.
Reported-by: Doug Junkins <junkins@foghead.com>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When adding a gas change event via a context menu, the gas-id and
timestamp were passed in two distinct ways.
1) The gas id was extracted from the text of the action. This meant
doing rather complicated parsing.
2) The timestamp was passed via the "user data" of the action, which
means transporting via "QVariant".
There is a much simpler way to pass arbitrary data, that is strongly
typed: lambdas. Instead of shoehorning the data onto the action in
an archaic way, we can simply connect to a stateful lambda. That's
what they're for after all.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This adds a tab for dive log - related preferences.
A suitable test programs is still required.
Signed-off-by: willemferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
qmlprofile.* is part of profile-widget, and are now defined in the
the corresponding CMakeLists.txt, and thereby making the central
CMakeLists.txt cleaner.
Signed-off-by: Jan Iversen <jan@casacondor.com>
This property is used to render the profile of a given dive.
Weirdly, even though the diveId is an integer, it was stored
as a string. It is not clear why that is the case. Therefore,
turn into the more natural int and avoid unnecessary conversion.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The tooltip's plotInfo was not cleared when clearing the profile.
With the new cylinder code, this lead to crashes, because the
displayed_dive's cylinder array is now cleared. The old code would
happily read stale data from the fixed-size cylinders array.
Clear the plotInfo explicitly.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In the future we might want to use undo-commands for mobile as
well (even if not implementing undo).
Therefore, move the undo-command source from desktop-widgets
to their own commands top-level folder.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of accessing the cylinder table directly, use the get_cylinder()
function. This gives less unwieldy expressions. But more importantly,
the function does bound checking. This is crucial for now as the code
hasn't be properly audited since the change to arbitrarily sized
cylinder tables. Accesses of invalid cylinder indexes may lead to
silent data-corruption that is sometimes not even noticed by
valgrind. Returning NULL instead of an invalid pointer will make
debugging much easier.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
TankItem would happily access a non-existing cylinder and crash.
But freedives for example have no cylinders. Thus, handle that
situation gracefully by exiting early if there is no cylinder.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of using fixed size arrays, use a new cylinder_table structure.
The code copies the weightsystem code, but is significantly more complex
because cylinders are such an integral part of the core.
Two functions to access the cylinders were added:
get_cylinder() and get_or_create_cylinder()
The former does a simple array access and supposes that the cylinder
exists. The latter is used by the parser(s) and if a cylinder with
the given id does not exist, cylinders up to that id are generated.
One point will make C programmers cringe: the cylinder structure is
passed by value. This is due to the way the table-macros work. A
refactoring of the table macros is planned. It has to be noted that
the size of a cylinder_t is 64 bytes, i.e. 8 long words on a 64-bit
architecture, so passing on the stack is probably not even significantly
slower than passing as reference.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Some widgets copy the full plot info. Free these data on exit to
prevent monstrous valgrind reports.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Continue with replacing pointers to struct plot_data entries
by indexes. Thus the pressure data can be kept in its own
array and can by dynamically sized.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The ProfileWidget2::getEntryFromPos() function was only used
by code that was commented out. Thus comment it out as well.
Moreover, turn the accompanying FIXME comments into TODO comments
to avoid a new LGTML alert.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The goal here is to make it possible to detach the pressure related
data from the plot_info structure. Thus, the pressure related data
can be allocated independently depending on the number of cylinders
per dive.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To make the pressure data dynamic (size of the arrays depending
on the cylinders in the dive), it has to be separated from the
standard plot_data structure. To enable this, use indexes instead
of pointers to plot_data elements. This commit converts
the RulerItem2 to use an index.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When keeping track of cylinder related data, the code was using
static arrays of MAX_CYLINDERS length. If we want to use dynamically
sized cylinder arrays, these have to be dynamically allocated.
In C++ code, this is trivial: simply replace the C-style arrays
by std::vector<>. Don't use QVector, as no reference counting or
COW semantics are needed here. These are purely local and unshared
arrays.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
