aboutsummaryrefslogtreecommitdiffstats
path: root/profile-widget/profilewidget2.h
AgeCommit message (Collapse)Author
2021-08-18Add (nonfunctional) dive computer rename hooksGravatar Linus Torvalds
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>
2021-07-30cleanup: unify the ProfileWidget2::shouldCalculateMax* variablesGravatar Berthold Stoeger
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>
2021-07-03profile: remove ProfileWidget2::ItemsGravatar Berthold Stoeger
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>
2021-07-03profile: rename ADD state to EDIT stateGravatar Berthold Stoeger
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>
2021-07-03cleanup: remove lost comment in profilewidget2.hGravatar Berthold Stoeger
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>
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-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-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: 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-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: 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: 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-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-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-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-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: 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>
2021-01-10profile: collect dive-profile items in a vectorGravatar Berthold Stoeger
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>
2021-01-10profile: remove ProfileWidget2::setupItem()Gravatar Berthold Stoeger
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>
2021-01-10profile: construct PP gas items with createPPGas() functionGravatar Berthold Stoeger
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>
2021-01-10profile: move allocation of DiveProfileItems into a templateGravatar Berthold Stoeger
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>
2021-01-10profile: initialize axis of DiveProfileItems on constructionGravatar Berthold Stoeger
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2021-01-10profile: remove ProfileWidget2::dateTimeChanged()Gravatar Berthold Stoeger
This function sent a signal and the only listener was removed in the previous commit. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-12-20profile: remove clearHandlers function (fixes crash)Gravatar Berthold Stoeger
Recently (674c20227b2), 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>
2020-12-19profile: move picture removal from DivePictureItem to ProfileWidget2Gravatar Berthold Stoeger
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>
2020-12-12cleanup: remove unused signal ProfileWidget2::updateDiveInfoGravatar Berthold Stoeger
Last user was remove in 0bd821183d. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-12-12profile: move DiveHandler to profile-widget folderGravatar Berthold Stoeger
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>
2020-12-12profile: call clearHandlers() in setPlanState()Gravatar Berthold Stoeger
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>
2020-05-06undo: make picture (media) deletion undoableGravatar Berthold Stoeger
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>
2020-05-06undo: implement undo of setting a picture time by drag&dropGravatar Berthold Stoeger
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>
2020-05-03profile: don't interpret NULL as current_dive in plotDive()Gravatar Berthold Stoeger
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>
2020-05-03profile: use member-to-function style connect() statementsGravatar Berthold Stoeger
This makes things compile-time instead of run-time checked. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-05-03cleanup: remove parameter to ProfleWidget2::replot()Gravatar Berthold Stoeger
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>
2020-04-13cleanup: remove protected access specifier in ProfileWidget2Gravatar Berthold Stoeger
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>
2020-04-12profile: remove ProfileWidget2::replotEnabledGravatar Berthold Stoeger
The last setter was removed in the previous commit. Let's remove this complexity. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-04-07undo: replot profile if event changedGravatar Berthold Stoeger
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>
2020-04-07cleanup: demote slots in ProfileWidget2 to private functionsGravatar Berthold Stoeger
Since we call these with lambdas, they don't need to be slots anymore. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-04-07cleanup: use lambdas to transport DiveEventItem to actionsGravatar Berthold Stoeger
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>
2020-04-07cleanup: use lambda to transport event-time to context menu actionsGravatar Berthold Stoeger
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>
2020-04-07profile: use lambda for addDivemodeSwitch callsGravatar Berthold Stoeger
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>
2020-04-07undo: update profile on cylinder editingGravatar Berthold Stoeger
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>
2020-01-30Cleanup: remove redundant(?) commentGravatar Berthold Stoeger
We don't have such a comment anywhere in the code base. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-01-30Profile: transport gas id and timestamp via lambdaGravatar Berthold Stoeger
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>