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 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>
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>
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 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>
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>
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>
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>
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 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 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>
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>
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>
The ProfileWidget2::recalcCeiling() function is used in one place,
namely when an undo-command changes the mode. It recalculates
decompression data and repaints the ceilings and thus avoids a
full profile-redraw.
This is smart, but it becomes problematic when the dive is changed
and the ceiling is recalculated before the profile is redrawn.
The DivePlotDataModel then still has data from the previous dive
but cylinders of the new dive are accessed.
This kind of situation may arise if multiple dive fields are
updated, as for example when replanning a dive.
Currently, this only causes a temporary mis-calculation. When
removing MAX_CYLINDERS this will lead to crashes.
One might attempt to fix the whole data-dependency mess. This
commit goes the cheap route and simply redraws the profile when
the mode is changed. Yes, it is in a way ineffective, but we
do worse things. The ProfileWidget2::recalcCeiling() thus becomes
unused and is removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The plotDive() function had a flag to plot pictures asynchronously.
This was used on export. Rename this field to "instant" and disable
animations when set. This should make sure that the axes are properly
exported.
Fixes#2170
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When exporting dive pictures we don't want animations. Therefore,
store the animation speed in the profile object to avoid nasty
hacks with the preferences.
This actually removes such a hack. Pictures and tooltips for now
still use the values stored in the preferences, because their
animations happen only on user-interactions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The whole edit logic moved from displayed_dive to current_dive
and it became more and more tedious to keep these in sync.
Therefore, simply always display current_dive. The only exceptions
are the equipment tab and the planner, as these are not yet
integrated in the undo system. Once this is done, displayed_dive
can be removed.
Moreover, remove the clear parameter from updateDiveInfo().
Instead simply clear of there is no current_dive set.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Allow splitting out a dive computer into a distinct dive. This
is realized by generating a base class from SplitDive.
This turned out to be more cumbersome than expected: we don't
know a-priori which of the split dives will come first. Since
the undo-command saves the indices where the dives will be insert,
these have to be calculated. This is an premature optimization,
which makes more pain than necessary. Let's remove it and
simply determine the insertion index when executing the command.
Original code by Linus Torvalds <torvalds@linux-foundation.org>.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The pictures of the current dive were plotted on the profile.
In principle OK, as this is what the user is shown. Only on
export this results in all profiles having the same pictures.
Therefore, pass a dive argument to the picture-plotting function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The thumbnails were fetched in the background to achieve a
snappier UI. The problem with that is that on LaTeX etc.
export only placeholder thumbnails were shown.
Therefore, implement a synchronous mode. This only tries
to fetch cached thumbnails or calculate thumbnails for
images. Videos and remote files are not supported.
Fixes#1963
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
With Facebook support gone, we should offer a way to export
the profile image. This has been part of the TeX support
but this makes it explicit.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
This reverts commit 1c4a859c8d,
where the override modifiers were removed owing to the noisy
"inconsistent override modifiers" which is default-on in clang.
This warning was disabled in 77577f717f,
so we can reinstate the overrides.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
These were pointers into the global prefs object. The user must
not use these to modify the settings, therefore make them
pointers-to-const.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Commit df156a56c0 replaced "virtual"
by "override" where appropriate. Unfortunately, this had the
unintended consequence of producing numerous clang warnings. If
clang finds a override-modified function in a class definition,
it warns for *all* overriden virtual functions without the override
modifier.
To solve this, go the easy route and remove all overrides. At least
it is consistent.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The keyword "virtual" signalizes that the function is virtual,
i.e. the function of the derived class is called, even if the
call is on the parent class.
It is not necessary to repeat the "virtual" keyword in derived
classes. To highlight derived virtual functions, the keyword
"override" should be used instead. It results in a hard compile-
error, if no function is overridden, thus avoiding subtle bugs.
Replace "virtual" by "override" where appropriate. Moreover,
replace Q_DECL_OVERRIDE by override, since we require reasonably
recent compilers anyway. Likewise, replace /* reimp */ by
"override" for consistency and compiler support.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Paint a rectangle on top of thumbnails indicating the run-time
of the video.
Use the z=100.0-101.0 range for painting the thumbnails, whereby
the z-value increases uniformly from first to last thumbnail
(sorted by timestamp). The duration-bars are placed at z-values
midway between those of the thumbnails.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Gracefully handle drag & drop to the profile, which changes the
offset of the pictures. To do this, keep the pictures in the
DivePictureModel and the ProfileWidget2 sorted by offset and
re-arrange if needed to keep the list sorted. This needs some
code reshuffling.
Introduce a helper-function that moves ranges in arrays.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If pictures were deleted, the remaining thumbails where staying at
their positions. Only when switching between dives, the new positions
were recalculated. Do the recalculation immediately. More precisely:
the x-coordinate, which is determined by the timestamp, stays identical.
Only the y-coordinate is recalculated such that overlapping of thumbnails
is avoided.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As long as ProfileWidget2 and DivePictureModel showed the same set of
pictures and any change would lead to a full recalculation of the set,
it made sense to let ProfileWidget2 use DivePictureModel's data.
Recently, keeping the two lists in sync become more and more of a
burden. Therefore, disconnect ProfileWidget2 and DivePictureModel. This
will lead to some code-duplication and perhaps a temporary drop in
UI-performance, but in the end the code is distinctly simpler and also
more flexible.
Thus, for example the DivePhotoTab could be changed to support headings
without having to touch ProfileWidget2 at all.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
On deletion of a single or multiple pictures, the whole DivePictureModel
was repopulated, which was clearly visible in the UI, owing to the
reconstructing of all images in the profile plot.
To avoid this vexing behavior, implement proper deletion routines in
DivePictureModel and ProfileWidget2. Since this needs sensible erase()
semantics the QList<PictureEntry> member of DivePictureModel was
replaced by a QVector. A QVector should be the default anyway, unless
there are very specific reasons to use a QList (which actually is
a deque, not a classical linked list).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In MainWindow::current_dive_changed() first plotDive() is called,
which replots all the pictures by calling plotPictures(). This
is pointess, because it plots the pictures of the previous dive.
Then, updateDiveInfo() is called, which resets the dive pictures
and automatically replots them. Thus, switching between dives
both with hundreds of pictures is way slower than necessary.
Switching the plotDive() and updateDiveInfo() calls doesn't work.
The reason is not 100% clear, but it doesn't make sense to plot
pictures of the new dive as long as the profile still shows the
old dive anyway.
As a quick-fix, add a flag to plotDive(), which tells the function
to clear the pictures list instead of redrawing it.
Ultimately, plotDive() should probably be split in two functions.
One for the callers who update the pictures themselves and one
for the others.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This commit allows plotting the OC-equivalent pO2 graph for PSCR
dives. This happens in both the cases where there is no external
O2-monitoring AND when there is external pO2 monitoring. The
calculations are only done for PSCR dives and is achieved as
follows:
1) Within plot-info create a pressure-t called OC_pO2 in
profile.h and populate this variable with the open-circuit
pO2 values in profile.c.
2) Create a new partialPressureGasItem ocpo2GasItem in
profilewidget2.h and, in profilewidget2.cpp, initialise it
to read the plot-info OC_pO2 values and enable its
display by using the setVisible method. The
diveplotdatamodel was also touched in order to achieve
this.
3) Create a pref button that controls the display of OC-pO2 for SCR dives
4) Change the colour of the OC-pO2 grpah to orange
5) Change the connection of the crr_OC_pO2 signal to be appropriate
6) rename the OC_pO2 attribute to scr_OC-pO2
Signed-off-by: Willem Ferguson <willemferguson@zoology.up.ac.za>
Only update those pictures of the DivePictureModel that actually changed.
This will be useful once pictures are loaded incrementally.
To do so, replace the pictures array by an array with stable ids. Before
this commit, not-shown pictures are left out of the pictures array, which
makes the mapping from DivePictureModel-ids to the picture array index
non-trivial.
Replace the QList<DivePictureItem *> by a std::vector<std::unique_ptr<DivePictureItem>>
to ease memory management. Sadly, owing to COW semantics, QVector is incompatible
with QScopedPointer.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Move divepicturemodel.cpp to the desktop only category and deal
with the (limited) fallout. We, currently, do not support dive
pictures tied to the profile on mobile, so there is no use
including this code.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
All the deleted items were added to the scene, which takes
"ownership" (a remarkably fuzzy concept in Qt) of these
objects. In principle, deleting these items is a bug - even
though it is handled gracefully.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
report_error() now does this automatically. So all these odd places in which we tried
to make sure that we show errors are no longer needed.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For CCR dives we want to display the setpoint and pO2 information,
due to the limited screensize we have to remove the temperature graph or
the view will be to cluttered.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
Having subsurface-core as a directory name really messes with
autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an
autocomplete conflict and also was inconsistent with the desktop-widget
name for the directory containing the "other" UI.
And while cleaning up the resulting change in the path name for include
files, I decided to clean up those even more to make them consistent
overall.
This could have been handled in more commits, but since this requires a
make clean before the build, it seemed more sensible to do it all in one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We were creating a couple dozen objects that we never needed and because
of that triggered several dozen callbacks whenever the model data changed.
All for UI elements of the profile that are either not used in the mobile
app (like the calculated ceiling or the partial pressure / tissue
saturation graphs), or are only useful when using the profile
interactively (which we also don't do on mobile).
I don't know if this will make a significant impact on performance, but it
seems like the right thing to do either way.
A positive side effect is that the odd blue line on top of the rendered
profile is gone as well.
Fixes#1007
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
start of the QSettinsg Object Wrapper usage on the code
this first patch removes two macros that generated around
200 lines in runtime for something like a quarter of it
Basically, whenever we changed anything we called the
PreferencesDialog::settingsChanged and connected everythign
to that signal, now each setting has it's own changed signal
and we can call it directly.
The best thing about this approach is that we don't trigger
repaints for things that are not directly profile related. (
actually we still do, but the plan is to remove them in due time)
this commit breaks correct atualization of the profile (because
everything was connected to PreferencesDialog::settingsChanged)
and now I need to hunt a bit for the correct connections
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now that we have the possibility to add images without meaningful
time stamps to a dive, we should let the user provide that time
offset manually. This patch allowed pictures to be dragged from
the image list to the profile.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
DiveCalculatedCeiling is the last class the references
MainWindow in the profile-widget stack.
In modelDataChanged() it looks for the information()
widget and sets a slot for the dateTimeChanged() signal that
information() emits.
To solve the issue we make DiveCalculatedCeiling recieve
a ProfileWidget2 reference and make ProfileWidget2 emit
the dateTimeChangedItems() signal.
ProfileWidget2 itself listens for the dateTimeChanged()
signal that information() emits and emits dateTimeChangedItems()
to notify any possible children/item listeners in the
ProfileWidget2::dateTimeChanged() slot.
The connection between ProfileWidget2 and information()
is set in MainWindow. This makes DiveCalculatedCeiling
unaware of MainWindow and which class originally emits
the dateTimeChanged() signal to ProfileWidget2.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
--
Think delegation.
Tomaz, please take a look at this one, to double check
if i messed up.
also i have zero idea how the mobile app is setting these
connections, if it does so even.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And action can't not just trigger a slot, it can also send a signal.
With this there is no reference to the MainWindow left in the profile.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of directly calling into the MainWindow, redirect this via a
signal so Subsurface mobile can hook it up as needed.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I'm not sure we can ever run into this issue anymore since we stop
calculating TTS / NDL past 2 hours, but I guess on a fairly slow CPU this
still could take too long.
But instead of calling into MainWindow let's just change the setting right
here and add a signal to show the notification - that way we can use the
appropriate way to make such notifications on the mobile app.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The reason for that is, even if profile widget is made with qpainter
and for that reason it should be a desktop widget, it's being used
on the mobile version because of a lack of QML plotting library that
is fast and reliable.
We discovered that it was faster just to encapsulate our Profile in
a QML class and call it directly.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
