It simplifies reasoning about control flow a lot if it is known
that functions can't be invoked from a different part of the code
base.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The way the starting time of a new plan was set was bonkers:
1) PlannerWidgets::planDive() invokes DivePlannerPointsModel::
createSimpleDive().
2) createSimpleDive() calls DivePlannerPointsModel::
setupStartTime()
3) setupStartTime() emits a signal startTimeChanged()
4) startTimeChanged is caught by PlannerWidget and sets
the UI field
5) change of the UI field emits a timeChanged() signal which
is connected to DivePlannerPointsModel::setStartTime()
6) setStartTime() sets the time of the plan and displayed_dive
and emits dataChanged()
7) dataChanged() replots the dive()
8) Back in DivePlannerPointsModel::createSimpleDive() the diveplan
start time is overwritten with displayed_dive (the value are
equal owing to 6)
Wow!
But it gets worse:
9) The initial dive plan is set up in createSimpleDive().
Since the profile is drawn in 7) after clearing the displayed_dive
and before constructing the initial plan, the profile is shown
on a dive without samples. It therefore generates a dummy profile.
To make this somewhat less insane, remove the startTimeChanged()
signal in 3), explicitly set the start time of plan and dive to
the one calculated by setupStartTime() and explicitly set the UI
filed in the plannerWidget.
This still indirectly draws the profile via signals in a convoluted
way, but at it straightens out things somewhat. Most importantly,
the profile doesn't have to generate a fake DC.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There are two sets of messages that tend to dominate the logs
- the RSSI updates from the Qt BLE stack
- the warnings about deprecated signal use in Kirigami
Neither of them provide any value to us when trying to find bugs; and
often they end up hiding the things that we really care about. So let's
just not log them - which is easy as we have our own message handler.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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 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>
These functions return the maximum partial pressures in the
given dive. Obviously, being pure accessors, they should be
const.
This commit also replaces the macro generating these functions
by a call to a function taking a pointer-to-member. Arguably,
C++'s pointer-to-member syntax is just as horrible as macros,
but at least it doesn't mess with syntax highlighting of
my editor and should be better to debug.
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>
This function was not used anywhere. Moreover, remove a few
unused includes from qthelper.h. Surprisingly, a number of users
of qthelper.h depend on these, so readd them at the appropriate
places.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Arguably, the number of filtered dives is a matter of the divefilter.
Let's move it there.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The shown_dives variable was reset by the dive_list code. Arguably,
the filter should keep track of the number of shown dives, so move
the resetting there. This means adding a new "reset()" member function
to the filter and call that instead of "updateAll()" when the core
data is reset.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When editing a dive, a DiveObjectHelper of the unmodified dive
was created to compare the edited with the old values. Since
the DiveObjectHelper is used here only as a pointless wrapper
around the formatting functions, call these functions directly.
However, note that the code is in principle wrong since the
change to the mobile-models, which do not use the DiveObjectHelper.
The real fix would be to reload the data from the model to prevent
going out-of-sync with respect to the formatting routines!
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
At this point (post grantlee), DiveObjectHelper is just pointless
glue code. Let's remove it from the printing code and call the
formatting functions directly. If necessary, move these functions
to core/string-format.cpp.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The mobile version of the list used string formatting functions
defined in DiveObjectHelper and declared in mobilelistmodels.h.
Very confusing. Move them to a separate source file where - in
the long run - all the string-formatting functions, which
are scattered all over the place, can be collected.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The list of known tank types were kept in a fixed size table.
Instead, use a dynamic table with our horrendous table macros.
This is more flexible and sensible.
While doing this, clean up the TankInfoModel, which was leaking
memory.
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>
We'll need this in order to be able to actually open dive files and
download things from a dive computer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
in_planner() is problematic, since it is uses desktop-only
application state. Since the cylinder-model already has
an appropriate inPlanner flag, use this instead.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The in_planner() function is problematic, because it depends
on the application state that is only available on desktop.
If we ever want to port the planner to mobile, we have to get
rid of it. Luckily, the DivePlannerModel already has an
appropriate flag that can be used instead.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of programatically reload the completion models, listen
to the relevant signals in the models. To that goal, derive all
the models from a base class.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There were macros to auto-generate functions to reload the models.
One was only used once and therefore is pointless. The other can
be replaced by a function with a pointer-to-member-variable argument.
While doing this, adapt the coding style.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Qt's memory management scheme is completely broken and messes
with common expectations.
QObjects are organized as a tree. The children are destroyed
in the destructor of QObject. This means that they are destructed
after the destructor of the parent object has run and its
sub-object were destructed. Obviously, this makes no sense as
the child objects should be able to access their parent at
any time.
To restore the commonly expected deterministic order of
construction and destruction, one might simply do away with
Qt's silly object tree and organise things using classical
subobjects. However, that breaks with the Qt-generated UI
classes: The objects generated by these classes are *not*
destructed with the UI class. Instead, they are attached
to the widget's QObject tree. Thus these are again destructed
*after* the widget! Who comes up with such a scheme?
In our case this means that we cannot have models used for
TableViews as subobjects, because the TableView needs the
model to save the column widths in the destructor. Which,
as detailed above is called *after* the desctructor of the
widget! Thus, turn these models into heap-allocated objects
and add them to the QObject tree.
Funilly, this exposes another insanity of Qt's QObject tree:
Children are destructed in order of construction! One would
expect that if objects are constructed in the sequence
A, B, C one can expect that C can, at any time, access B and A.
Not so in Qt: The destruction order is likewise A, B, C!
Thus, take care to init the widgets before the model. Jeez.
Finally, print a warning in the column-saving code of
TableWidget, so that these kind of subtleties are caught
in the future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
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>
This was used by the DiveComputerDialog, which does not exist
anymore. The new tab uses the function in the corresponding
sorted model.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of modifying the device table directly, call the undo
commands. Moreover, don't keep our own copy in the mode - show
the original version. Connect to the appropriate signals.
This means that the calls from the DiveComputerManagement
dialog have to be removed, since this mode of editing is
not supported. The whole dialog will be removed in a future
commit.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To implement undo-semantics, we want a longer-lived dive-computer-model
(currently, it is regenerated when the dialog is opened). Therefore, it
must be reloaded when the core data is reset. Do this like for other
models: listen to the dataReset() signal of DiveListNotifier.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
If we want to include dive computer names in the undo system,
there should be visual feedback on undo/redo.
This would mean opening the divecomputer dialog, which would
appear quite strange. Therefore, add a tab. This is not ideal,
but consistent with the dive site tab, which probably shouldn't
be there either. In the future, the UI needs some rethinking.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Technically get_dive(i) could return a nullptr. But given the range for i that
can never happen. Still, the test is extremely cheap and doesn't hurt.
Fixes CID 354768
Fixes CID 354766
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In one weird case (suunto), the code in libdivecomputer.c
generates a device node directly instead of going the usual
way (setting the data in the dc-structure of the imported
dive). It is unclear to me whether that has to be that way,
as it depends on the chronological order of callbacks to
event_cb() and dive_cb().
Therefore add a device_table pointer to device_data_t
so that the downloader can add the device to this table. This
only adds the pointer, but does not yet use it in the
downloading code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a device_table parameters to Command::importTable() and
add_imported_dives(). The content of this table will be added
to the global device list (respectively removed on undo).
This is currently a no-op, as the parser doesn't yet fill
out the device table, but adds devices directly to the global
device table.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Since we converted from QString to std::string, let's also use
std::vector instead of QVector. We don't need COW semantics
and all the rigmarole. Let's try to keep Qt data structures
out of the core.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
struct device is a core data structure and therefore shouldn't use QString.
QString stores as UTF-16 (which is a very questionable choice in itself).
However, the real problem is that this puts us in lifetime-management
hell when interfacing with C code: The UTF-16 has to be converted to
UTF-8, but when returning such a string, this puts burden on the caller
who has to free it. In fact, instead of looping over devices from C-code
we had a callback that sent down temporary C-strings with qPrintable.
In contrast, std::string is guaranteed to store its data as
contiguous null-terminated and C-compatible strings. Therefore,
replace the QString by std::string. Keep the QString just in
one place that formats a hexadecimal number to avoid any
potential change.
The disadvantage of using std::string is that it will crash
when constructed with a NULL argument, consistent with C-style
functions such as strcmp, etc. Arguably, NULL is different
from the empty string even though we treat both as the same.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a small proxy-model on top of DiveComputerModel so that clicking
on table headers makes the table sortable.
The UI feature here is not as important as the fact that the UI does
its own sorting and we can keep the device-table in the core sorted
differently.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We keep track of device, i.e. distinct dive computers with id in the core.
The corresponding code stuck out like a sore thumb. Firstly, because it
is C++. But more importantly, because it used inconsistent nameing conventions.
Notably it defined a "DiveComputerNode" when this is something very different
from "struct dive_computer", the latter being the dive-computer related
data of a single dive.
Since the whole thing is defined in "device.h" and the function to create
such an entry is called "create_device_node", call the structure "device".
Use snake_case for consistency with the other core structures.
Moreover, call the collection of devices "device_table" in analogy
with "dive_table", etc.
Overall, this should make the core code more consistent style-wise.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When moving dives between trips, the core moves the dives internally
and sends a signal to the model. The model adds and removes the dives
accordingly. However, when adding the new dive, the old trip hasn't
changed its position, so the ordering is wrong leading to an inconsistent
state.
Therefore, remove the dives first and then readd them. There could
still be pathological cases where this fails. However, in the short
term this is an improvement. Note that in similar cases, the dives were
indeed removed then added, so this case here seems to be an oversight.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
getDiveSelection() returns a vector of the selected dives.
Use that instead of looping over the dive table and checking
manually.
This removes a few lines of code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The get_trip_date_string() formatted, as the name implies, the date
of a trip. It was passed a number of parameters and had only one
caller, which would also add the location if it existed.
Therefore, move all that logic into the helper function and
name it get_trip_string().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When importing a divelog, import filter presets. If there are
equal names, import only if the presets differ. In that case,
disambiguate the name. This made things a bit more complicated,
as comparison of filter presets had to be implemented.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Implement a trivial model to provide the filter preset names
to the UI. Sadly, for now this features the QWidget/QML
column / name dichotomy. However, in this simple case that
shouldn't be too much of an issue.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a model that keeps track of a list of filter constraint and makes
them accessible from Qt. Sadly, this is mostly repetitive boiler-plate
code, but this is due to Qt's model/view-API, which is a perfect example
of how *not* to design a reasonable modern API.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The cylinder model is used both in the planner and the
equipment tab. We have three preferences for the pO2 that
is used to compute MOD: In the planner, there is one for
the bottom part of the dive and another one for deco.
Those are set in the planenr UI. There is another value,
controlled in the Tec Prefernces. That one should be
used in the equipment tab rather than the one from
the planner.
Fixes#2984
Signed-off-by: Robert C. Helling <helling@atdotde.de>
If the dive timestamp changes, the dive could move in the dive list. But the
current dive actually doesn't change (it's still the same dive, right?). Yet
we need to update the dive list as well as the shown dive (especially if this
is after adding a dive, which is first inserted with the current time and then
updated with whatever the user enters).
Fixes: #2971
Suggested-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
At some time, when introducing the global reset signal the filter
stopped being reloaded when loading a new log. This leads to very
strange UI behavior: dives disappear when editing fields unrelated
to the filter.
Therefore, when reloading the model, reset the filter. One might
argue whether this is the correct place. On the other hand, we
might even make the filter a sub-object of the dive-list model.
Let's think about this.
Partially solves #2961
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
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>
