This has become a bit of a catch-all overhaul of a large portion of the
planner - I started out wanting to improve the CCR mode, but then as I
started pulling all the other threads that needed addressing started to
come with it.
Improve how the gas selection is handled when planning dives in CCR
mode, by making the type (OC / CCR) of segments dependent on the gas use
type that was set for the selected gas.
Add a preference to allow the user to chose to use OC gases as diluent,
in a similar fashion to the original implementation.
Hide gases that cannot be used in the currently selected dive mode in
all drop downs.
Include usage type in gas names if this is needed.
Hide columns and disable elements in the 'Dive planner points' table if
they can they can not be edited in the curently selected dive mode.
Visually identify gases and usage types that are not appropriate for the
currently selected dive mode.
Move the 'Dive mode' selection to the top of the planner view, to
accommodate the fact that this is a property of the dive and not a
planner setting.
Show a warning instead of the dive plan if the plan contains gases that
are not usable in the selected dive mode.
Fix the data entry for the setpoint in the 'Dive planner points' table.
Fix problems with enabling / disabling planner settings when switching
between dive modes.
Refactor some names to make them more appropriate for their current
usage.
One point that is still open is to hide gas usage graphs in the planner
profile if the gas isn't used for OC, as there is no way to meaningfully
interpolate such usage.
Signed-off-by: Michael Keller <github@ike.ch>
Fix the persisting and use of gradient factor preferences for dive
profiles in the mobile version.
Also rename the mobile backend gradient factor settings to make it
obvious that they are used by the (not currently enabled) planner.
Signed-off-by: Michael Keller <github@ike.ch>
Add an option for users to sync the dive computer time with the PC time
every time dives are downloaded.
Obviously this will only work on dive computers that have time
synchronisation support in libdivecomputer, for other computers a notice
is logged.
The selection for this option is persisted as a preference.
Signed-off-by: Michael Keller <github@ike.ch>
Since we now use a model to calculate the dive summary, there
is no need to export recalculation of the dive summary via
QMLInterface.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of transporting the global first and last dive date
in the dive summary, calculate it in an external function.
Since we already have time and date functions in qthelper.cpp
implement those functions there. Provide a stub in QMLInterface
so that QML can access these standalone functions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Usually, we use PascalCase (i.e. camelCase with a capital
letter at the start) for class names. For consistency, let's
do it here as well.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
QMLInterface::instance() is only used in one single place. This
makes the whole notion of having a global instance of the object
moot, isn't it?
Simply make the object static to the function that uses it, which
guarantees that the object will be created when the function is
called. I.e. the same behavior is retained with less complexity.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
It appears weird to connect the QMLInterface signal/slot combination
in a static helper function. This generates a bunch of lambdas that
call the instance() function.
Instead, simply do the connections in the constructor as we do it
in numerous other places.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add dive_move variable to qmlinterface, to make it aviable to QML.
Signed-off-by: jan Iversen <jan@casacondor.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Create DiveSummary class in backend-shared and make the DiveSummary calculation
results available to QML.
This adds a loop over all dives (could have been done with a model, but the
models available to mobile are very limited, so use the basic way).
[Dirk Hohndel: renamed the results variable and combined a couple of commits]
Signed-off-by: jan Iversen <jan@casacondor.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add surface_segment to plannerShared and then
update desktop-widgets.
Signed-off-by: jan Iversen <jan@casacondor.com>
desktop-widgets: use plannerShared for surface_segment
Change getter/setter for surface_segment to plannerShared, in
order to share the conversion with mobile diveplanner
Signed-off-by: jan Iversen <jan@casacondor.com>
Duplicate deco_mode to DECO_MODE, in order to make it available to QML.
Duplicate enum divemode_t to DIVE_MODE in order to make it
available to QML. Only part of the enum is made available.
Signed-off-by: jan Iversen <jan@casacondor.com>
Add bottompo2, decopo2 and bestmixend to QMLInterface
Bestmixend in gas options changing with
meter/feet
Signed-off-by: jan Iversen <jan@casacondor.com>
Move conversion cuft <-> liter from desktop-widget/diveplanner.cpp
to plannerShared, to facilitate the same results in mobile
diveplanner
Use Backend for bottomsac/decosac and update to check
for switch LITER <-> CUFT
Add bottomsac/decosac to QMLinterface.
Signed-off-by: jan Iversen <jan@casacondor.com>
Add simple variables, where getter uses prefs. and setters call directly to set
function (without using plannerShared).
rename last_stop --> last_stop6m
Signed-off-by: jan Iversen <jan@casacondor.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Make notes rates available to QML through the Backend interface.
Remove the corresponding variables from plannerShared.
Getters are from prefs. while setters are linked to diveplan model.
Remark: signals from qPrefDivePlanner is used, because the diveplanner model
sets qPrefDivePlanner but do not issue special signals.
Signed-off-by: jan Iversen <jan@casacondor.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Make ascent/descent rates available to QML through the Backend interface.
Remark signals from qPrefDivePlanner is used because the diveplanner model
sets qPrefDivePlanner but does not issue its own signals.
Signed-off-by: jan Iversen <jan@casacondor.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add qPrefUnit Q_PROPERTY but using QMLInterface enums, that way
all variables become strongly typed in QML.
Signed-off-by: jan Iversen <jan@casacondor.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add CLOUD_STATUS enum to interface.
Add cloud_verifification_status variable to interface, and make
it strongly typed in QML.
using backend.cloud_verification_status = 1 will fail but
backend.cloud_verification_status = backend.CS_UNKNOWN is correct.
Added note to the original definitions of the enums that they have been
duplicated.
Signed-off-by: jan Iversen <jan@casacondor.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add a header file that contains a duplicate of the enums,
that are needed in QML in one class.
the unit enums are added imidiatly, since they are needed
or will be neede shortly in Settings and DivePlannerSettings
This class will also contain Q_PROPERTY and signal/slot for
variables used in QML. This is done to allow e.g.
deco_mode qPrefUnits::planner_deco_mode()
void qPrefUnits::set_planner_deco_mode(deco_mode)
as strongly typed in C++
and
DECO_MODE planner_deco_mode()
void set_planner_deco_mode(DECO_MODE)
as strongly typed in QML
Remark: wrong assignments gives errors in QML
The advantage over using strings or the value directly is that
QML detects typos and flags them as errors/warnings.
It is important to note that the class may only contain
a) a function call to the implementation
b) a reference to a global variable e.g. prefs.
Added note to the original definitions of the enums that they
have been duplicated.
Signed-off-by: jan Iversen <jan@casacondor.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>