aboutsummaryrefslogtreecommitdiffstats
path: root/profile-widget/profilewidget2.cpp
AgeCommit message (Collapse)Author
2021-07-03profile: remove EDIT_STATE from ProfileWidget2Gravatar Berthold Stoeger
This state is not used anywhere. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-06-29cleanup: remove unused item in ProfileWidget2's ItemPosGravatar Berthold Stoeger
This is most likely an artifact from a long time ago. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-06-27cleanup: factor out duplicate axis-initialization codeGravatar Berthold Stoeger
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>
2021-06-05profile: remove internal event-copy (fix deleting/renaming events)Gravatar Berthold Stoeger
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>
2021-06-05profile: pass axes and model to DiveEventItem on constructionGravatar Berthold Stoeger
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>
2021-06-05profile: pass event at construction time to DiveEventItemGravatar Berthold Stoeger
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>
2021-06-04profile: remove unused function ProfileWidget2::getPrintMode()Gravatar Berthold Stoeger
The last user was removed in the previous commit. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-05-08profile: rename GF_LINE color to DURATION_LINEGravatar Berthold Stoeger
The color was misnamed, since it has only been used for the duration line for quite some time (since 893bea700c98 to be exact). Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-05-08profile: remove DiveAmbPressureItemGravatar Berthold Stoeger
This was replaced by the tissue map in 893bea700c98. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-05-08profile: remove DiveGFLineItemGravatar Berthold Stoeger
This was replaced by the tissue map in 893bea700c98. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-04-26profile: move checking for DiveTextItem into its own functionGravatar Berthold Stoeger
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>
2021-04-26profile: simplify checking for DiveTextItemGravatar Berthold Stoeger
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>
2021-04-26cleanup: remove unnecessary includes from profilewidget2.cppGravatar Berthold Stoeger
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>
2021-04-25profile: ignore animation-speed setting when printingGravatar Berthold Stoeger
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>
2021-04-10profile: remove enableToolbar() signalGravatar Berthold Stoeger
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>
2021-04-10profile: remove force parameter from ProfileWidget2::plotDive()Gravatar Berthold Stoeger
The last user was removed in 2789bb05b133a7cf54081d58d4f5c51c8977e951. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-04-10profile: remove [disable|enable]Shortcuts() signalsGravatar Berthold Stoeger
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>
2021-04-02profile/planner: don't update dive in ProfileWidget2::plotDive()Gravatar Berthold Stoeger
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>
2021-04-02planner: split addStop() into external and internal versionsGravatar Berthold Stoeger
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>
2021-04-02profile: populate dive handlers when switching to edit/plan modeGravatar Berthold Stoeger
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>
2021-04-02planner: split createTemporaryPlan() function.Gravatar Berthold Stoeger
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>
2021-04-02profile: remove redundant replot() calls in key eventsGravatar Berthold Stoeger
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>
2021-04-02profile: make ItemPos initialization constantGravatar Berthold Stoeger
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>
2021-04-02profile: display arbitrary diveGravatar Berthold Stoeger
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>
2021-04-02profile: don't check for stepping past maximum time / depthGravatar Berthold Stoeger
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>
2021-04-02profile: fix logic in keyDeleteAction()Gravatar Berthold Stoeger
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>
2021-04-02planner: move clearing of model into loadFromDive() functionGravatar Berthold Stoeger
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>
2021-04-02planner: move same-time check to DivePlannerPointsModelGravatar Berthold Stoeger
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>
2021-04-02profile: remove special casing of handle movingGravatar Berthold Stoeger
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>
2021-04-02profile: pass DivePlannerPointsModel at construction timeGravatar Berthold Stoeger
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>
2021-04-02profile: connect to DivePointsPlannerModel in separate functionGravatar Berthold Stoeger
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>
2021-04-02planner: implement move semantics in DivePlannerPointsModelGravatar Berthold Stoeger
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>
2021-04-02profile: implement proper model/view semantics in ProfileWidget2Gravatar Berthold Stoeger
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>
2021-04-02profile use unique_ptr to manage dive handler objectsGravatar Berthold Stoeger
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>
2021-02-17planner: pass in_planner argument to replot()Gravatar Berthold Stoeger
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>
2021-02-17planner: pass in_planner argument to decoMode()Gravatar Berthold Stoeger
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>
2021-02-06profile: detect dive-mode change in profileGravatar Berthold Stoeger
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>
2021-01-20cleanup: remove dive parameter from DivePlotDataModel::setDive()Gravatar Berthold Stoeger
This was not used, probably an artifact from days long gone. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-01-20profile: don't "fake" dc in profile widgetGravatar Berthold Stoeger
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>
2021-01-20profile: make three member functions constGravatar Berthold Stoeger
These accessors do not change the ProfileWidget2 state, so make them const. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-01-19mobile: add GF fields for ceiling calculationGravatar Doug Junkins
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>
2021-01-10mobile/profile: show calculated ceiling if enabledGravatar Dirk Hohndel
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>
2021-01-10profile: remove firstCall static variableGravatar Berthold Stoeger
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>
2021-01-10profile: pass dive to DiveHandlerGravatar Berthold Stoeger
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>
2021-01-10profile: pass dive to RulerItemGravatar Berthold Stoeger
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>
2021-01-10profile: pass dive to ToolTipItem::refresh()Gravatar Berthold Stoeger
Don't access the global displayed_dive variable in a step to make the profile reentrant. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-01-10profile: pass dive to plot function of profile-itemsGravatar Berthold Stoeger
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>
2021-01-10profile: pass dive to EventItemGravatar Berthold Stoeger
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>
2021-01-10profile: use a parameter to determine planner stateGravatar Berthold Stoeger
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>
2021-01-10profile: unconditionally replot chart when settings changeGravatar Berthold Stoeger
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>