If the user never clicks on the log and dump checkboxes (and that's what
we expect to be the case by default), then the log / dump flags (and
filenames) were never initialized.
I am reasonably certain this will close the following three bugs, that all
show the same symptom: they behave as if libdivecomputer dump was set,
even if it wasn't.
Fixes: #426Fixes: #431Fixes: #435
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
C++ style of accessing single instance class object.
Signed-off-by: Boris Barbulovski <bbarbulovski@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If you need to use this->error to distinguish the local variable from the
object membe that should be a hint that maybe you didn't pick the best
name for the local variable.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
* Add missing variable members to the initializer lists.
Signed-off-by: Boris Barbulovski <bbarbulovski@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Another futile attempt to cleanup the code and make coding style and
whitespace consistent. I tried to add a file that describes the key points
of our coding style. I have no illusions that this will help the least
bit...
This commit should ONLY change whitespace
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the 'logfile_name' and 'dumpfile_name' were NULL we can simply
strdup() them with a new value, but if there was a previous value
we need to free() first.
C99 6.7.8 allows us to keep said variables without the
explicit NULL initialiazation.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This patch disables/enables the DC device node based on what type of
transport the selected DC uses. The only time the device node field is
used is if the selected DC uses a serial transport type. IrDA and USB type
transports do not use the device node.
Signed-off-by: Benjamin Fogel <nystire@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Subsurface creates a lot of singleton instances on demand, but nothing
ever deleted them. Since they are singletons, these memory allocations
are technically not leaks. However, they clutter the output in valgrind
and other memory analysers, hiding the real issues.
The solution is to delete these items at exit. For the models and for
gettextFromC, the solution is to use a QScopedPointer, which will delete
its payload when it gets destroyed. For the dialogs and other widgets,
we can't do that: they need to be deleted before QApplication exits, so
we just set the parent in all of them to the main window.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a bit hacky and simply adds the title to the message text when
compiling on a Mac, but hopefully this will be enough.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So in case the OK button was relabeled to 'Retry', relabel it back to OK.
Also, 'Retry' should be capitalized.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Don't do "obvious cleanups" at 4 in the morning when you can't sleep because
of emotionally draining issues outside of your control... and if you do,
at least compile test them.
This was introduced by me in commit 2f9f46cb0253 ("Random white space
cleanup").
Sorry.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I just went thru all of subsurface code removing
some whitespaces issues and trying to make the
code prettyer, I also removed a few QString issues.d
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
This means we don't have to new/delete them, which is a waste of
overhead.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This means we can also remove the forward declarations.
This is the first step in removing the memory allocation for the ui
sub-classes. Without the second step, this commit is just making the
compilation time increase for no good reason :-)
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
* Removes the InterfaceThread
which is basically an unecessary proxy between the MainThread and
the DownloadThread.
* Use a state machine to control the DownloadWidget UI logic.
Signed-off-by: Danilo Cesar Lemes de Paula <danilo.eu@gmail.com>
The DownloadDialog behavior was broken in a way it allows the user
to make changes on the dialog while the download is happening.
Also, clicking on "Cancel" breaks/hangs the UI sometimes, as libdivingcomputer
doesn't always cancels the download right away. That's a bug that
still needs to be fixed.
Signed-off-by: Danilo Cesar Lemes de Paula <danilo.eu@gmail.com>
While most dialogs can be open and the main application window
can still be accessed, certain should possibly be modal
in these terms.
This patch proposes the download from webservice and DC dialogs
to lock the main application window until they are closed, with
the consideration of preventing eventual unexpected behavior
in the divelist if both dialogs are active at the same time.
To solve that QtDialog::exec() is used instead of
QtWidget::show().
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Most child windows should be closed with the main application
window otherwise if left open and if making specific
modifictions could potentially cause a SIGSEGV.
To solve that we mark all custom windows/dialogs with
the Qt::WA_QuitOnClose attribute on instance creation.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This behaves somewhat differently from the Gtk version - still needs
more investigation. But at least now it's hooked in.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The old gtk branch started out with device_data_t explicitly cleared,
but the Qt version never did that. And we actually depend on the
deviceid in particular being initialized to zero (and then we fill in
the details in the divecomputer download callbacks)
Not properly initializing it meant that we ended up with random
deviceid's that got added to the divecomputer device lists, and then
saved to the XML file without actually matching the data in the dive
computers in the actual *dives*.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The download already worked, but we didn't display the new dives. This
introduces a new slot for MainWindow that updates what is displayed in
Subsurface after files were imported.
With this change we can successfully download ONCE - but when trying to
download a second dive the dialog doesn't appear to get refreshed the
right way - the OK button doesn't appear to work anymore (Cancel however
does).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The data is saved in the settings and the correct dive computer (vendor
and product) and device are picked when the download dialog is openend.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Small changes to the names of elements the divecomputer download UI and
very simplistic first stab at populating the device_data_t structure.
This is lacking lots of things
- it should remember the last vendor / product used
- it should figure out which device (mount point) to offer
- it needs proper error handling
But it's a step in the right direction.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This uses the QStringListModel to populate the items
of the QComboBoxes. I used a QHash to hold every Computer
of a particular Vendor. so, products[vendor] gives me
the full list of products from each vendor.
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
I think it's self explanatory - When user clicks on
'Cancel', the interface will wait for the trhead to quit
then will close itself.
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
This is the skeleton code for a non-blocking ui-thread
It already creates the first-thread ( 'do not block the ui' )
and the second thread ('download from the dive computer')
We can in the future merge both in the same place - I didn't
want to do that now because the download function is written
in the libdivecomputer.c code, and I cant just transform that
to a QThread and use signals, so I used two threads for that.
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
