2017-04-27 18:24:53 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2014-05-30 06:56:27 +00:00
|
|
|
#include "configuredivecomputer.h"
|
2015-01-08 22:14:18 +00:00
|
|
|
#include <QTextStream>
|
2014-06-10 16:19:28 +00:00
|
|
|
#include <QFile>
|
2014-06-11 06:37:27 +00:00
|
|
|
#include <libxml/parser.h>
|
|
|
|
|
#include <libxml/parserInternals.h>
|
|
|
|
|
#include <libxml/tree.h>
|
|
|
|
|
#include <libxslt/transform.h>
|
|
|
|
|
#include <QStringList>
|
2014-07-06 03:53:42 +00:00
|
|
|
#include <QXmlStreamWriter>
|
2019-08-05 18:07:10 +00:00
|
|
|
#include "core/file.h"
|
2019-08-05 17:41:15 +00:00
|
|
|
#include "core/errorhelper.h"
|
2017-09-28 03:00:58 +00:00
|
|
|
#include "core/version.h"
|
2014-06-10 16:19:28 +00:00
|
|
|
|
2014-12-29 04:56:58 +00:00
|
|
|
ConfigureDiveComputer::ConfigureDiveComputer() : readThread(0),
|
2014-10-17 22:33:47 +00:00
|
|
|
writeThread(0),
|
2014-10-20 20:58:21 +00:00
|
|
|
resetThread(0),
|
|
|
|
|
firmwareThread(0)
|
2014-05-30 06:56:27 +00:00
|
|
|
{
|
|
|
|
|
setState(INITIAL);
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-04 19:00:21 +00:00
|
|
|
void ConfigureDiveComputer::connectThreadSignals(DeviceThread *thread)
|
|
|
|
|
{
|
|
|
|
|
connect(thread, &DeviceThread::finished, this, &ConfigureDiveComputer::readThreadFinished, Qt::QueuedConnection);
|
|
|
|
|
connect(thread, &DeviceThread::error, this, &ConfigureDiveComputer::setError);
|
|
|
|
|
connect(thread, &DeviceThread::progress, this, &ConfigureDiveComputer::progressEvent, Qt::QueuedConnection);
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-10 15:25:25 +00:00
|
|
|
void ConfigureDiveComputer::readSettings(device_data_t *data)
|
2014-05-30 06:56:27 +00:00
|
|
|
{
|
|
|
|
|
setState(READING);
|
|
|
|
|
|
|
|
|
|
if (readThread)
|
|
|
|
|
readThread->deleteLater();
|
|
|
|
|
|
2014-06-10 15:25:25 +00:00
|
|
|
readThread = new ReadSettingsThread(this, data);
|
2020-10-04 19:00:21 +00:00
|
|
|
connectThreadSignals(readThread);
|
|
|
|
|
connect(readThread, &ReadSettingsThread::devicedetails, this, &ConfigureDiveComputer::deviceDetailsChanged);
|
2014-05-30 06:56:27 +00:00
|
|
|
|
|
|
|
|
readThread->start();
|
|
|
|
|
}
|
|
|
|
|
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
void ConfigureDiveComputer::saveDeviceDetails(const DeviceDetails &details, device_data_t *data)
|
2014-05-30 07:49:58 +00:00
|
|
|
{
|
2014-06-10 15:25:25 +00:00
|
|
|
setState(WRITING);
|
2014-05-30 07:49:58 +00:00
|
|
|
|
2014-06-10 15:25:25 +00:00
|
|
|
if (writeThread)
|
|
|
|
|
writeThread->deleteLater();
|
|
|
|
|
|
|
|
|
|
writeThread = new WriteSettingsThread(this, data);
|
2020-10-04 19:00:21 +00:00
|
|
|
connectThreadSignals(writeThread);
|
2014-06-10 15:25:25 +00:00
|
|
|
|
|
|
|
|
writeThread->setDeviceDetails(details);
|
|
|
|
|
writeThread->start();
|
2014-06-07 18:56:44 +00:00
|
|
|
}
|
|
|
|
|
|
2019-03-24 10:31:44 +00:00
|
|
|
static QString writeGasDetails(gas g)
|
|
|
|
|
{
|
|
|
|
|
return QStringList({
|
|
|
|
|
QString::number(g.oxygen),
|
|
|
|
|
QString::number(g.helium),
|
|
|
|
|
QString::number(g.type),
|
|
|
|
|
QString::number(g.depth)
|
|
|
|
|
}).join(QLatin1Char(','));
|
|
|
|
|
}
|
|
|
|
|
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
bool ConfigureDiveComputer::saveXMLBackup(const QString &fileName, const DeviceDetails &details, device_data_t *data)
|
2014-06-10 16:19:28 +00:00
|
|
|
{
|
|
|
|
|
QString xml = "";
|
|
|
|
|
QString vendor = data->vendor;
|
|
|
|
|
QString product = data->product;
|
2014-07-06 03:53:42 +00:00
|
|
|
QXmlStreamWriter writer(&xml);
|
|
|
|
|
writer.setAutoFormatting(true);
|
|
|
|
|
|
|
|
|
|
writer.writeStartDocument();
|
|
|
|
|
writer.writeStartElement("DiveComputerSettingsBackup");
|
|
|
|
|
writer.writeStartElement("DiveComputer");
|
|
|
|
|
writer.writeTextElement("Vendor", vendor);
|
|
|
|
|
writer.writeTextElement("Product", product);
|
|
|
|
|
writer.writeEndElement();
|
|
|
|
|
writer.writeStartElement("Settings");
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
writer.writeTextElement("CustomText", details.customText);
|
2014-06-21 06:31:19 +00:00
|
|
|
//Add gasses
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
writer.writeTextElement("Gas1", writeGasDetails(details.gas1));
|
|
|
|
|
writer.writeTextElement("Gas2", writeGasDetails(details.gas2));
|
|
|
|
|
writer.writeTextElement("Gas3", writeGasDetails(details.gas3));
|
|
|
|
|
writer.writeTextElement("Gas4", writeGasDetails(details.gas4));
|
|
|
|
|
writer.writeTextElement("Gas5", writeGasDetails(details.gas5));
|
2014-06-21 06:31:19 +00:00
|
|
|
//
|
2014-06-21 06:53:05 +00:00
|
|
|
//Add dil values
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
writer.writeTextElement("Dil1", writeGasDetails(details.dil1));
|
|
|
|
|
writer.writeTextElement("Dil2", writeGasDetails(details.dil2));
|
|
|
|
|
writer.writeTextElement("Dil3", writeGasDetails(details.dil3));
|
|
|
|
|
writer.writeTextElement("Dil4", writeGasDetails(details.dil4));
|
|
|
|
|
writer.writeTextElement("Dil5", writeGasDetails(details.dil5));
|
2017-03-06 12:36:42 +00:00
|
|
|
|
|
|
|
|
//Add setpoint values
|
2014-06-21 07:22:47 +00:00
|
|
|
QString sp1 = QString("%1,%2")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
.arg(QString::number(details.sp1.sp),
|
|
|
|
|
QString::number(details.sp1.depth));
|
2014-06-21 07:22:47 +00:00
|
|
|
QString sp2 = QString("%1,%2")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
.arg(QString::number(details.sp2.sp),
|
|
|
|
|
QString::number(details.sp2.depth));
|
2014-06-21 07:22:47 +00:00
|
|
|
QString sp3 = QString("%1,%2")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
.arg(QString::number(details.sp3.sp),
|
|
|
|
|
QString::number(details.sp3.depth));
|
2014-06-21 07:22:47 +00:00
|
|
|
QString sp4 = QString("%1,%2")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
.arg(QString::number(details.sp4.sp),
|
|
|
|
|
QString::number(details.sp4.depth));
|
2014-06-21 07:22:47 +00:00
|
|
|
QString sp5 = QString("%1,%2")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
.arg(QString::number(details.sp5.sp),
|
|
|
|
|
QString::number(details.sp5.depth));
|
2014-07-06 03:53:42 +00:00
|
|
|
writer.writeTextElement("SetPoint1", sp1);
|
|
|
|
|
writer.writeTextElement("SetPoint2", sp2);
|
|
|
|
|
writer.writeTextElement("SetPoint3", sp3);
|
|
|
|
|
writer.writeTextElement("SetPoint4", sp4);
|
|
|
|
|
writer.writeTextElement("SetPoint5", sp5);
|
2014-06-21 07:22:47 +00:00
|
|
|
|
|
|
|
|
//Other Settings
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
writer.writeTextElement("DiveMode", QString::number(details.diveMode));
|
|
|
|
|
writer.writeTextElement("Saturation", QString::number(details.saturation));
|
|
|
|
|
writer.writeTextElement("Desaturation", QString::number(details.desaturation));
|
|
|
|
|
writer.writeTextElement("LastDeco", QString::number(details.lastDeco));
|
|
|
|
|
writer.writeTextElement("Brightness", QString::number(details.brightness));
|
|
|
|
|
writer.writeTextElement("Units", QString::number(details.units));
|
|
|
|
|
writer.writeTextElement("SamplingRate", QString::number(details.samplingRate));
|
|
|
|
|
writer.writeTextElement("Salinity", QString::number(details.salinity));
|
|
|
|
|
writer.writeTextElement("DiveModeColor", QString::number(details.diveModeColor));
|
|
|
|
|
writer.writeTextElement("Language", QString::number(details.language));
|
|
|
|
|
writer.writeTextElement("DateFormat", QString::number(details.dateFormat));
|
|
|
|
|
writer.writeTextElement("CompassGain", QString::number(details.compassGain));
|
|
|
|
|
writer.writeTextElement("SafetyStop", QString::number(details.safetyStop));
|
|
|
|
|
writer.writeTextElement("GfHigh", QString::number(details.gfHigh));
|
|
|
|
|
writer.writeTextElement("GfLow", QString::number(details.gfLow));
|
|
|
|
|
writer.writeTextElement("PressureSensorOffset", QString::number(details.pressureSensorOffset));
|
|
|
|
|
writer.writeTextElement("PpO2Min", QString::number(details.ppO2Min));
|
|
|
|
|
writer.writeTextElement("PpO2Max", QString::number(details.ppO2Max));
|
|
|
|
|
writer.writeTextElement("FutureTTS", QString::number(details.futureTTS));
|
|
|
|
|
writer.writeTextElement("CcrMode", QString::number(details.ccrMode));
|
|
|
|
|
writer.writeTextElement("DecoType", QString::number(details.decoType));
|
|
|
|
|
writer.writeTextElement("AGFSelectable", QString::number(details.aGFSelectable));
|
|
|
|
|
writer.writeTextElement("AGFHigh", QString::number(details.aGFHigh));
|
|
|
|
|
writer.writeTextElement("AGFLow", QString::number(details.aGFLow));
|
|
|
|
|
writer.writeTextElement("CalibrationGas", QString::number(details.calibrationGas));
|
|
|
|
|
writer.writeTextElement("FlipScreen", QString::number(details.flipScreen));
|
|
|
|
|
writer.writeTextElement("SetPointFallback", QString::number(details.setPointFallback));
|
|
|
|
|
writer.writeTextElement("LeftButtonSensitivity", QString::number(details.leftButtonSensitivity));
|
|
|
|
|
writer.writeTextElement("RightButtonSensitivity", QString::number(details.rightButtonSensitivity));
|
|
|
|
|
writer.writeTextElement("BottomGasConsumption", QString::number(details.bottomGasConsumption));
|
|
|
|
|
writer.writeTextElement("DecoGasConsumption", QString::number(details.decoGasConsumption));
|
|
|
|
|
writer.writeTextElement("ModWarning", QString::number(details.modWarning));
|
|
|
|
|
writer.writeTextElement("DynamicAscendRate", QString::number(details.dynamicAscendRate));
|
|
|
|
|
writer.writeTextElement("GraphicalSpeedIndicator", QString::number(details.graphicalSpeedIndicator));
|
|
|
|
|
writer.writeTextElement("AlwaysShowppO2", QString::number(details.alwaysShowppO2));
|
2014-07-06 03:53:42 +00:00
|
|
|
|
2014-10-12 14:51:27 +00:00
|
|
|
// Suunto vyper settings.
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
writer.writeTextElement("Altitude", QString::number(details.altitude));
|
|
|
|
|
writer.writeTextElement("PersonalSafety", QString::number(details.personalSafety));
|
|
|
|
|
writer.writeTextElement("TimeFormat", QString::number(details.timeFormat));
|
2014-10-12 14:51:27 +00:00
|
|
|
|
|
|
|
|
writer.writeStartElement("Light");
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
writer.writeAttribute("enabled", QString::number(details.lightEnabled));
|
|
|
|
|
writer.writeCharacters(QString::number(details.light));
|
2014-10-12 14:51:27 +00:00
|
|
|
writer.writeEndElement();
|
|
|
|
|
|
|
|
|
|
writer.writeStartElement("AlarmTime");
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
writer.writeAttribute("enabled", QString::number(details.alarmTimeEnabled));
|
|
|
|
|
writer.writeCharacters(QString::number(details.alarmTime));
|
2014-10-12 14:51:27 +00:00
|
|
|
writer.writeEndElement();
|
|
|
|
|
|
|
|
|
|
writer.writeStartElement("AlarmDepth");
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
writer.writeAttribute("enabled", QString::number(details.alarmDepthEnabled));
|
|
|
|
|
writer.writeCharacters(QString::number(details.alarmDepth));
|
2014-10-12 14:51:27 +00:00
|
|
|
writer.writeEndElement();
|
|
|
|
|
|
2014-07-06 03:53:42 +00:00
|
|
|
writer.writeEndElement();
|
|
|
|
|
writer.writeEndElement();
|
|
|
|
|
|
|
|
|
|
writer.writeEndDocument();
|
2014-06-10 16:19:28 +00:00
|
|
|
QFile file(fileName);
|
|
|
|
|
if (!file.open(QIODevice::WriteOnly)) {
|
2014-07-31 15:51:38 +00:00
|
|
|
lastError = tr("Could not save the backup file %1. Error Message: %2")
|
2014-12-29 04:56:58 +00:00
|
|
|
.arg(fileName, file.errorString());
|
2014-06-10 16:19:28 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
//file open successful. write data and save.
|
|
|
|
|
QTextStream out(&file);
|
|
|
|
|
out << xml;
|
|
|
|
|
|
|
|
|
|
file.close();
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
bool ConfigureDiveComputer::restoreXMLBackup(const QString &fileName, DeviceDetails &details)
|
2014-06-11 06:37:27 +00:00
|
|
|
{
|
2014-07-22 16:38:30 +00:00
|
|
|
QFile file(fileName);
|
|
|
|
|
if (!file.open(QIODevice::ReadOnly)) {
|
2014-07-31 15:51:38 +00:00
|
|
|
lastError = tr("Could not open backup file: %1").arg(file.errorString());
|
2014-06-11 06:37:27 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-22 16:38:30 +00:00
|
|
|
QString xml = file.readAll();
|
|
|
|
|
|
|
|
|
|
QXmlStreamReader reader(xml);
|
|
|
|
|
while (!reader.atEnd()) {
|
|
|
|
|
if (reader.isStartElement()) {
|
|
|
|
|
QString settingName = reader.name().toString();
|
2014-10-12 14:51:27 +00:00
|
|
|
QXmlStreamAttributes attributes = reader.attributes();
|
2014-07-22 16:38:30 +00:00
|
|
|
reader.readNext();
|
|
|
|
|
QString keyString = reader.text().toString();
|
|
|
|
|
|
|
|
|
|
if (settingName == "CustomText")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.customText = keyString;
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "Gas1") {
|
|
|
|
|
QStringList gasData = keyString.split(",");
|
|
|
|
|
gas gas1;
|
|
|
|
|
gas1.oxygen = gasData.at(0).toInt();
|
|
|
|
|
gas1.helium = gasData.at(1).toInt();
|
|
|
|
|
gas1.type = gasData.at(2).toInt();
|
|
|
|
|
gas1.depth = gasData.at(3).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.gas1 = gas1;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
2014-06-11 06:37:27 +00:00
|
|
|
|
2014-07-22 16:38:30 +00:00
|
|
|
if (settingName == "Gas2") {
|
|
|
|
|
QStringList gasData = keyString.split(",");
|
|
|
|
|
gas gas2;
|
|
|
|
|
gas2.oxygen = gasData.at(0).toInt();
|
|
|
|
|
gas2.helium = gasData.at(1).toInt();
|
|
|
|
|
gas2.type = gasData.at(2).toInt();
|
|
|
|
|
gas2.depth = gasData.at(3).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.gas2 = gas2;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "Gas3") {
|
|
|
|
|
QStringList gasData = keyString.split(",");
|
|
|
|
|
gas gas3;
|
|
|
|
|
gas3.oxygen = gasData.at(0).toInt();
|
|
|
|
|
gas3.helium = gasData.at(1).toInt();
|
|
|
|
|
gas3.type = gasData.at(2).toInt();
|
|
|
|
|
gas3.depth = gasData.at(3).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.gas3 = gas3;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "Gas4") {
|
|
|
|
|
QStringList gasData = keyString.split(",");
|
|
|
|
|
gas gas4;
|
|
|
|
|
gas4.oxygen = gasData.at(0).toInt();
|
|
|
|
|
gas4.helium = gasData.at(1).toInt();
|
|
|
|
|
gas4.type = gasData.at(2).toInt();
|
|
|
|
|
gas4.depth = gasData.at(3).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.gas4 = gas4;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "Gas5") {
|
|
|
|
|
QStringList gasData = keyString.split(",");
|
|
|
|
|
gas gas5;
|
|
|
|
|
gas5.oxygen = gasData.at(0).toInt();
|
|
|
|
|
gas5.helium = gasData.at(1).toInt();
|
|
|
|
|
gas5.type = gasData.at(2).toInt();
|
|
|
|
|
gas5.depth = gasData.at(3).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.gas5 = gas5;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "Dil1") {
|
|
|
|
|
QStringList dilData = keyString.split(",");
|
|
|
|
|
gas dil1;
|
|
|
|
|
dil1.oxygen = dilData.at(0).toInt();
|
|
|
|
|
dil1.helium = dilData.at(1).toInt();
|
|
|
|
|
dil1.type = dilData.at(2).toInt();
|
|
|
|
|
dil1.depth = dilData.at(3).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.dil1 = dil1;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "Dil2") {
|
|
|
|
|
QStringList dilData = keyString.split(",");
|
|
|
|
|
gas dil2;
|
|
|
|
|
dil2.oxygen = dilData.at(0).toInt();
|
|
|
|
|
dil2.helium = dilData.at(1).toInt();
|
|
|
|
|
dil2.type = dilData.at(2).toInt();
|
|
|
|
|
dil2.depth = dilData.at(3).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.dil1 = dil2;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "Dil3") {
|
|
|
|
|
QStringList dilData = keyString.split(",");
|
|
|
|
|
gas dil3;
|
|
|
|
|
dil3.oxygen = dilData.at(0).toInt();
|
|
|
|
|
dil3.helium = dilData.at(1).toInt();
|
|
|
|
|
dil3.type = dilData.at(2).toInt();
|
|
|
|
|
dil3.depth = dilData.at(3).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.dil3 = dil3;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "Dil4") {
|
|
|
|
|
QStringList dilData = keyString.split(",");
|
|
|
|
|
gas dil4;
|
|
|
|
|
dil4.oxygen = dilData.at(0).toInt();
|
|
|
|
|
dil4.helium = dilData.at(1).toInt();
|
|
|
|
|
dil4.type = dilData.at(2).toInt();
|
|
|
|
|
dil4.depth = dilData.at(3).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.dil4 = dil4;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
2014-06-11 06:37:27 +00:00
|
|
|
|
2014-07-22 16:38:30 +00:00
|
|
|
if (settingName == "Dil5") {
|
|
|
|
|
QStringList dilData = keyString.split(",");
|
|
|
|
|
gas dil5;
|
|
|
|
|
dil5.oxygen = dilData.at(0).toInt();
|
|
|
|
|
dil5.helium = dilData.at(1).toInt();
|
|
|
|
|
dil5.type = dilData.at(2).toInt();
|
|
|
|
|
dil5.depth = dilData.at(3).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.dil5 = dil5;
|
2014-06-11 06:37:27 +00:00
|
|
|
}
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "SetPoint1") {
|
|
|
|
|
QStringList spData = keyString.split(",");
|
|
|
|
|
setpoint sp1;
|
|
|
|
|
sp1.sp = spData.at(0).toInt();
|
|
|
|
|
sp1.depth = spData.at(1).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.sp1 = sp1;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "SetPoint2") {
|
|
|
|
|
QStringList spData = keyString.split(",");
|
|
|
|
|
setpoint sp2;
|
|
|
|
|
sp2.sp = spData.at(0).toInt();
|
|
|
|
|
sp2.depth = spData.at(1).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.sp2 = sp2;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "SetPoint3") {
|
|
|
|
|
QStringList spData = keyString.split(",");
|
|
|
|
|
setpoint sp3;
|
|
|
|
|
sp3.sp = spData.at(0).toInt();
|
|
|
|
|
sp3.depth = spData.at(1).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.sp3 = sp3;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "SetPoint4") {
|
|
|
|
|
QStringList spData = keyString.split(",");
|
|
|
|
|
setpoint sp4;
|
|
|
|
|
sp4.sp = spData.at(0).toInt();
|
|
|
|
|
sp4.depth = spData.at(1).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.sp4 = sp4;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "SetPoint5") {
|
|
|
|
|
QStringList spData = keyString.split(",");
|
|
|
|
|
setpoint sp5;
|
|
|
|
|
sp5.sp = spData.at(0).toInt();
|
|
|
|
|
sp5.depth = spData.at(1).toInt();
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.sp5 = sp5;
|
2014-07-22 16:38:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "Saturation")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.saturation = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "Desaturation")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.desaturation = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "DiveMode")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.diveMode = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "LastDeco")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.lastDeco = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "Brightness")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.brightness = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "Units")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.units = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "SamplingRate")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.samplingRate = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "Salinity")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.salinity = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "DiveModeColour")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.diveModeColor = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "Language")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.language = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "DateFormat")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.dateFormat = keyString.toInt();
|
2014-07-22 16:38:30 +00:00
|
|
|
|
|
|
|
|
if (settingName == "CompassGain")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.compassGain = keyString.toInt();
|
2014-10-12 14:51:27 +00:00
|
|
|
|
2014-10-17 22:33:46 +00:00
|
|
|
if (settingName == "SafetyStop")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.safetyStop = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "GfHigh")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.gfHigh = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "GfLow")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.gfLow = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "PressureSensorOffset")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.pressureSensorOffset = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "PpO2Min")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.ppO2Min = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "PpO2Max")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.ppO2Max = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "FutureTTS")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.futureTTS = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "CcrMode")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.ccrMode = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "DecoType")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.decoType = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "AGFSelectable")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.aGFSelectable = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "AGFHigh")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.aGFHigh = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "AGFLow")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.aGFLow = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "CalibrationGas")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.calibrationGas = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "FlipScreen")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.flipScreen = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
|
|
|
|
if (settingName == "SetPointFallback")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.setPointFallback = keyString.toInt();
|
2014-10-17 22:33:46 +00:00
|
|
|
|
2015-09-02 22:00:00 +00:00
|
|
|
if (settingName == "LeftButtonSensitivity")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.leftButtonSensitivity = keyString.toInt();
|
2015-09-02 22:00:00 +00:00
|
|
|
|
|
|
|
|
if (settingName == "RightButtonSensitivity")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.rightButtonSensitivity = keyString.toInt();
|
2015-09-02 22:00:00 +00:00
|
|
|
|
|
|
|
|
if (settingName == "BottomGasConsumption")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.bottomGasConsumption = keyString.toInt();
|
2015-09-02 22:00:00 +00:00
|
|
|
|
|
|
|
|
if (settingName == "DecoGasConsumption")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.decoGasConsumption = keyString.toInt();
|
2015-09-02 22:00:00 +00:00
|
|
|
|
|
|
|
|
if (settingName == "ModWarning")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.modWarning = keyString.toInt();
|
2015-09-02 22:00:00 +00:00
|
|
|
|
|
|
|
|
if (settingName == "DynamicAscendRate")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.dynamicAscendRate = keyString.toInt();
|
2015-09-02 22:00:00 +00:00
|
|
|
|
|
|
|
|
if (settingName == "GraphicalSpeedIndicator")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.graphicalSpeedIndicator = keyString.toInt();
|
2015-09-02 22:00:00 +00:00
|
|
|
|
|
|
|
|
if (settingName == "AlwaysShowppO2")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.alwaysShowppO2 = keyString.toInt();
|
2015-09-02 22:00:00 +00:00
|
|
|
|
2014-10-12 14:51:27 +00:00
|
|
|
if (settingName == "Altitude")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.altitude = keyString.toInt();
|
2014-10-12 14:51:27 +00:00
|
|
|
|
|
|
|
|
if (settingName == "PersonalSafety")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.personalSafety = keyString.toInt();
|
2014-10-12 14:51:27 +00:00
|
|
|
|
|
|
|
|
if (settingName == "TimeFormat")
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.timeFormat = keyString.toInt();
|
2014-10-12 14:51:27 +00:00
|
|
|
|
|
|
|
|
if (settingName == "Light") {
|
|
|
|
|
if (attributes.hasAttribute("enabled"))
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.lightEnabled = attributes.value("enabled").toString().toInt();
|
|
|
|
|
details.light = keyString.toInt();
|
2014-10-12 14:51:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "AlarmDepth") {
|
|
|
|
|
if (attributes.hasAttribute("enabled"))
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.alarmDepthEnabled = attributes.value("enabled").toString().toInt();
|
|
|
|
|
details.alarmDepth = keyString.toInt();
|
2014-10-12 14:51:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (settingName == "AlarmTime") {
|
|
|
|
|
if (attributes.hasAttribute("enabled"))
|
computer configuration: use value semantics for DeviceDetails
The memory managements for DeviceDetails was very sketchy.
First of all, sharing a pointer to a structure between threads
seems like a recipe for disaster. Secondly, the structure was
a QObject and when first generated included in the (silly)
Qt object tree, but when generated in the threads it was not.
Clearly, this leaks.
Instead, use value semantics and use local copies of the
structure. I didn't go full length and use std::move to
move the data, because this doesn't work through signals
(which are the wrong abstraction here, but OK) and secondly
I didn't have time to analyze whether the caller still
needs the data after passing it down to the worker thread.
To be able to pass an object through signals, the class
has to be registered in the Qt MetaType system. Super
ugly, but fine for now. Ultimately, this whole thing should
probably be replaced by futures, co-routines, or whatever.
Moreover, this removes the prefix from number of "m_*"
function parameters. By convention, "m_" marks member
variables, which function parameters are not.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
make DeviceDetails a metatype
So that we can pass it as value through the signal/slot system.
(squash with original commit)
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2024-03-16 08:29:54 +00:00
|
|
|
details.alarmTimeEnabled = attributes.value("enabled").toString().toInt();
|
|
|
|
|
details.alarmTime = keyString.toInt();
|
2014-10-12 14:51:27 +00:00
|
|
|
}
|
2014-06-11 06:37:27 +00:00
|
|
|
}
|
2014-07-22 16:38:30 +00:00
|
|
|
reader.readNext();
|
2014-06-11 06:37:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2024-01-15 20:22:20 +00:00
|
|
|
void ConfigureDiveComputer::startFirmwareUpdate(const QString &fileName, device_data_t *data, bool forceUpdate)
|
2014-06-23 15:16:27 +00:00
|
|
|
{
|
2014-10-20 20:58:21 +00:00
|
|
|
setState(FWUPDATE);
|
|
|
|
|
if (firmwareThread)
|
|
|
|
|
firmwareThread->deleteLater();
|
|
|
|
|
|
2023-03-02 12:01:46 +00:00
|
|
|
firmwareThread = new FirmwareUpdateThread(this, data, fileName, forceUpdate);
|
2020-10-04 19:00:21 +00:00
|
|
|
connectThreadSignals(firmwareThread);
|
2015-01-20 21:40:52 +00:00
|
|
|
|
2014-10-20 20:58:21 +00:00
|
|
|
firmwareThread->start();
|
2014-06-23 15:16:27 +00:00
|
|
|
}
|
|
|
|
|
|
2014-10-17 22:33:47 +00:00
|
|
|
void ConfigureDiveComputer::resetSettings(device_data_t *data)
|
|
|
|
|
{
|
|
|
|
|
setState(RESETTING);
|
|
|
|
|
|
|
|
|
|
if (resetThread)
|
|
|
|
|
resetThread->deleteLater();
|
|
|
|
|
|
|
|
|
|
resetThread = new ResetSettingsThread(this, data);
|
2020-10-04 19:00:21 +00:00
|
|
|
connectThreadSignals(resetThread);
|
2014-10-17 22:33:47 +00:00
|
|
|
|
|
|
|
|
resetThread->start();
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-20 21:40:52 +00:00
|
|
|
void ConfigureDiveComputer::progressEvent(int percent)
|
|
|
|
|
{
|
|
|
|
|
emit progress(percent);
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-30 06:56:27 +00:00
|
|
|
void ConfigureDiveComputer::setState(ConfigureDiveComputer::states newState)
|
|
|
|
|
{
|
|
|
|
|
currentState = newState;
|
|
|
|
|
emit stateChanged(currentState);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ConfigureDiveComputer::setError(QString err)
|
|
|
|
|
{
|
|
|
|
|
lastError = err;
|
2024-01-16 16:39:19 +00:00
|
|
|
emit error(std::move(err));
|
2014-05-30 06:56:27 +00:00
|
|
|
}
|
|
|
|
|
|
2014-05-30 07:49:58 +00:00
|
|
|
void ConfigureDiveComputer::readThreadFinished()
|
2014-05-30 06:56:27 +00:00
|
|
|
{
|
2014-05-30 07:49:58 +00:00
|
|
|
setState(DONE);
|
2015-05-27 19:19:11 +00:00
|
|
|
if (lastError.isEmpty()) {
|
2014-12-07 22:32:08 +00:00
|
|
|
//No error
|
|
|
|
|
emit message(tr("Dive computer details read successfully"));
|
|
|
|
|
}
|
2014-05-30 06:56:27 +00:00
|
|
|
}
|
|
|
|
|
|
2014-05-30 07:49:58 +00:00
|
|
|
void ConfigureDiveComputer::writeThreadFinished()
|
2014-05-30 06:56:27 +00:00
|
|
|
{
|
|
|
|
|
setState(DONE);
|
2015-05-27 19:19:11 +00:00
|
|
|
if (lastError.isEmpty()) {
|
2014-05-30 07:49:58 +00:00
|
|
|
//No error
|
|
|
|
|
emit message(tr("Setting successfully written to device"));
|
|
|
|
|
}
|
2014-05-30 06:56:27 +00:00
|
|
|
}
|
2014-10-17 22:33:47 +00:00
|
|
|
|
2014-10-20 20:58:21 +00:00
|
|
|
void ConfigureDiveComputer::firmwareThreadFinished()
|
|
|
|
|
{
|
|
|
|
|
setState(DONE);
|
2015-05-27 19:19:11 +00:00
|
|
|
if (lastError.isEmpty()) {
|
2014-10-20 20:58:21 +00:00
|
|
|
//No error
|
|
|
|
|
emit message(tr("Device firmware successfully updated"));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-17 22:33:47 +00:00
|
|
|
void ConfigureDiveComputer::resetThreadFinished()
|
|
|
|
|
{
|
|
|
|
|
setState(DONE);
|
2015-05-27 19:19:11 +00:00
|
|
|
if (lastError.isEmpty()) {
|
2014-10-17 22:33:47 +00:00
|
|
|
//No error
|
2014-11-01 00:07:14 +00:00
|
|
|
emit message(tr("Device settings successfully reset"));
|
2014-10-17 22:33:47 +00:00
|
|
|
}
|
|
|
|
|
}
|
2015-09-12 20:37:34 +00:00
|
|
|
|
|
|
|
|
QString ConfigureDiveComputer::dc_open(device_data_t *data)
|
|
|
|
|
{
|
|
|
|
|
FILE *fp = NULL;
|
|
|
|
|
dc_status_t rc;
|
|
|
|
|
|
2024-03-16 09:29:05 +00:00
|
|
|
if (data->libdc_log && !logfile_name.empty())
|
|
|
|
|
fp = subsurface_fopen(logfile_name.c_str(), "w");
|
2015-09-12 20:37:34 +00:00
|
|
|
|
|
|
|
|
data->libdc_logfile = fp;
|
|
|
|
|
|
|
|
|
|
rc = dc_context_new(&data->context);
|
|
|
|
|
if (rc != DC_STATUS_SUCCESS) {
|
|
|
|
|
return tr("Unable to create libdivecomputer context");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (fp) {
|
|
|
|
|
dc_context_set_loglevel(data->context, DC_LOGLEVEL_ALL);
|
|
|
|
|
dc_context_set_logfunc(data->context, logfunc, fp);
|
2017-09-28 03:00:58 +00:00
|
|
|
fprintf(data->libdc_logfile, "Subsurface: v%s, ", subsurface_git_version());
|
|
|
|
|
fprintf(data->libdc_logfile, "built with libdivecomputer v%s\n", dc_version(NULL));
|
2015-09-12 20:37:34 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-17 22:57:04 +00:00
|
|
|
rc = divecomputer_device_open(data);
|
2015-09-12 20:37:35 +00:00
|
|
|
|
|
|
|
|
if (rc != DC_STATUS_SUCCESS) {
|
2024-03-12 08:17:50 +00:00
|
|
|
report_error("%s", errmsg(rc));
|
2015-09-12 20:37:35 +00:00
|
|
|
} else {
|
2018-04-17 01:14:59 +00:00
|
|
|
rc = dc_device_open(&data->device, data->context, data->descriptor, data->iostream);
|
2015-09-12 20:37:35 +00:00
|
|
|
}
|
|
|
|
|
|
2015-09-12 20:37:34 +00:00
|
|
|
if (rc != DC_STATUS_SUCCESS) {
|
|
|
|
|
return tr("Could not a establish connection to the dive computer.");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
setState(OPEN);
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ConfigureDiveComputer::dc_close(device_data_t *data)
|
|
|
|
|
{
|
|
|
|
|
if (data->device)
|
|
|
|
|
dc_device_close(data->device);
|
|
|
|
|
data->device = NULL;
|
|
|
|
|
if (data->context)
|
|
|
|
|
dc_context_free(data->context);
|
|
|
|
|
data->context = NULL;
|
2018-04-17 01:14:59 +00:00
|
|
|
dc_iostream_close(data->iostream);
|
|
|
|
|
data->iostream = NULL;
|
2015-09-12 20:37:34 +00:00
|
|
|
|
|
|
|
|
if (data->libdc_logfile)
|
|
|
|
|
fclose(data->libdc_logfile);
|
|
|
|
|
|
|
|
|
|
setState(INITIAL);
|
|
|
|
|
}
|
