2019-03-09 21:32:16 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2022-09-18 11:49:29 +00:00
|
|
|
#include "divesitelistview.h"
|
2020-02-03 18:33:06 +00:00
|
|
|
#include "core/subsurface-qt/divelistnotifier.h"
|
core: introduce divelog structure
The parser API was very annoying, as a number of tables
to-be-filled were passed in as pointers. The goal of this
commit is to collect all these tables in a single struct.
This should make it (more or less) clear what is actually
written into the divelog files.
Moreover, it should now be rather easy to search for
instances, where the global logfile is accessed (and it
turns out that there are many!).
The divelog struct does not contain the tables as substructs,
but only collects pointers. The idea is that the "divelog.h"
file can be included without all the other files describing
the numerous tables.
To make it easier to use from C++ parts of the code, the
struct implements a constructor and a destructor. Sadly,
we can't use smart pointers, since the pointers are accessed
from C code. Therfore the constructor and destructor are
quite complex.
The whole commit is large, but was mostly an automatic
conversion.
One oddity of note: the divelog structure also contains
the "autogroup" flag, since that is saved in the divelog.
This actually fixes a bug: Before, when importing dives
from a different log, the autogroup flag was overwritten.
This was probably not intended and does not happen anymore.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2022-11-08 20:31:08 +00:00
|
|
|
#include "core/divelog.h"
|
2019-03-13 20:36:31 +00:00
|
|
|
#include "core/divesite.h"
|
2019-11-17 17:13:55 +00:00
|
|
|
#include "core/divefilter.h"
|
2019-03-09 21:32:16 +00:00
|
|
|
#include "qt-models/divelocationmodel.h"
|
2022-09-18 11:49:29 +00:00
|
|
|
#include "desktop-widgets/mainwindow.h"
|
2019-11-13 14:08:40 +00:00
|
|
|
#include "commands/command.h"
|
2019-03-09 21:32:16 +00:00
|
|
|
|
2019-11-02 21:52:27 +00:00
|
|
|
#include <QMessageBox>
|
2019-03-09 21:32:16 +00:00
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
DiveSiteListView::DiveSiteListView(QWidget *parent) : QWidget(parent)
|
2019-03-09 21:32:16 +00:00
|
|
|
{
|
|
|
|
|
ui.setupUi(this);
|
desktop: fix saving of column-widths of device and site tables
Qt's memory management scheme is completely broken and messes
with common expectations.
QObjects are organized as a tree. The children are destroyed
in the destructor of QObject. This means that they are destructed
after the destructor of the parent object has run and its
sub-object were destructed. Obviously, this makes no sense as
the child objects should be able to access their parent at
any time.
To restore the commonly expected deterministic order of
construction and destruction, one might simply do away with
Qt's silly object tree and organise things using classical
subobjects. However, that breaks with the Qt-generated UI
classes: The objects generated by these classes are *not*
destructed with the UI class. Instead, they are attached
to the widget's QObject tree. Thus these are again destructed
*after* the widget! Who comes up with such a scheme?
In our case this means that we cannot have models used for
TableViews as subobjects, because the TableView needs the
model to save the column widths in the destructor. Which,
as detailed above is called *after* the desctructor of the
widget! Thus, turn these models into heap-allocated objects
and add them to the QObject tree.
Funilly, this exposes another insanity of Qt's QObject tree:
Children are destructed in order of construction! One would
expect that if objects are constructed in the sequence
A, B, C one can expect that C can, at any time, access B and A.
Not so in Qt: The destruction order is likewise A, B, C!
Thus, take care to init the widgets before the model. Jeez.
Finally, print a warning in the column-saving code of
TableWidget, so that these kind of subtleties are caught
in the future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-11-07 12:20:46 +00:00
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
// What follows is duplicate code with locationinformation.cpp.
|
|
|
|
|
// We might want to unify this.
|
|
|
|
|
ui.diveSiteMessage->setCloseButtonVisible(false);
|
|
|
|
|
|
|
|
|
|
QAction *acceptAction = new QAction(tr("Done"), this);
|
|
|
|
|
connect(acceptAction, &QAction::triggered, this, &DiveSiteListView::done);
|
|
|
|
|
|
|
|
|
|
ui.diveSiteMessage->setText(tr("Dive site management"));
|
|
|
|
|
ui.diveSiteMessage->addAction(acceptAction);
|
|
|
|
|
|
desktop: fix saving of column-widths of device and site tables
Qt's memory management scheme is completely broken and messes
with common expectations.
QObjects are organized as a tree. The children are destroyed
in the destructor of QObject. This means that they are destructed
after the destructor of the parent object has run and its
sub-object were destructed. Obviously, this makes no sense as
the child objects should be able to access their parent at
any time.
To restore the commonly expected deterministic order of
construction and destruction, one might simply do away with
Qt's silly object tree and organise things using classical
subobjects. However, that breaks with the Qt-generated UI
classes: The objects generated by these classes are *not*
destructed with the UI class. Instead, they are attached
to the widget's QObject tree. Thus these are again destructed
*after* the widget! Who comes up with such a scheme?
In our case this means that we cannot have models used for
TableViews as subobjects, because the TableView needs the
model to save the column widths in the destructor. Which,
as detailed above is called *after* the desctructor of the
widget! Thus, turn these models into heap-allocated objects
and add them to the QObject tree.
Funilly, this exposes another insanity of Qt's QObject tree:
Children are destructed in order of construction! One would
expect that if objects are constructed in the sequence
A, B, C one can expect that C can, at any time, access B and A.
Not so in Qt: The destruction order is likewise A, B, C!
Thus, take care to init the widgets before the model. Jeez.
Finally, print a warning in the column-saving code of
TableWidget, so that these kind of subtleties are caught
in the future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-11-07 12:20:46 +00:00
|
|
|
model = new DiveSiteSortedModel(this);
|
2019-03-09 21:32:16 +00:00
|
|
|
ui.diveSites->setTitle(tr("Dive sites"));
|
desktop: fix saving of column-widths of device and site tables
Qt's memory management scheme is completely broken and messes
with common expectations.
QObjects are organized as a tree. The children are destroyed
in the destructor of QObject. This means that they are destructed
after the destructor of the parent object has run and its
sub-object were destructed. Obviously, this makes no sense as
the child objects should be able to access their parent at
any time.
To restore the commonly expected deterministic order of
construction and destruction, one might simply do away with
Qt's silly object tree and organise things using classical
subobjects. However, that breaks with the Qt-generated UI
classes: The objects generated by these classes are *not*
destructed with the UI class. Instead, they are attached
to the widget's QObject tree. Thus these are again destructed
*after* the widget! Who comes up with such a scheme?
In our case this means that we cannot have models used for
TableViews as subobjects, because the TableView needs the
model to save the column widths in the destructor. Which,
as detailed above is called *after* the desctructor of the
widget! Thus, turn these models into heap-allocated objects
and add them to the QObject tree.
Funilly, this exposes another insanity of Qt's QObject tree:
Children are destructed in order of construction! One would
expect that if objects are constructed in the sequence
A, B, C one can expect that C can, at any time, access B and A.
Not so in Qt: The destruction order is likewise A, B, C!
Thus, take care to init the widgets before the model. Jeez.
Finally, print a warning in the column-saving code of
TableWidget, so that these kind of subtleties are caught
in the future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-11-07 12:20:46 +00:00
|
|
|
ui.diveSites->setModel(model);
|
2019-03-12 16:28:43 +00:00
|
|
|
// Default: sort by name
|
|
|
|
|
ui.diveSites->view()->sortByColumn(LocationInformationModel::NAME, Qt::AscendingOrder);
|
|
|
|
|
ui.diveSites->view()->setSortingEnabled(true);
|
2019-03-16 11:09:58 +00:00
|
|
|
ui.diveSites->view()->horizontalHeader()->setSectionResizeMode(LocationInformationModel::NAME, QHeaderView::Stretch);
|
|
|
|
|
ui.diveSites->view()->horizontalHeader()->setSectionResizeMode(LocationInformationModel::DESCRIPTION, QHeaderView::Stretch);
|
2019-04-13 07:23:26 +00:00
|
|
|
ui.diveSites->view()->setSelectionBehavior(QAbstractItemView::SelectRows);
|
2019-03-09 21:32:16 +00:00
|
|
|
|
|
|
|
|
// Show only the first few columns
|
2019-03-14 21:07:48 +00:00
|
|
|
for (int i = LocationInformationModel::LOCATION; i < LocationInformationModel::COLUMNS; ++i)
|
2019-03-09 21:32:16 +00:00
|
|
|
ui.diveSites->view()->setColumnHidden(i, true);
|
2019-03-13 19:58:25 +00:00
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
connect(ui.diveSites, &TableView::addButtonClicked, this, &DiveSiteListView::add);
|
|
|
|
|
connect(ui.diveSites, &TableView::itemClicked, this, &DiveSiteListView::diveSiteClicked);
|
|
|
|
|
connect(ui.diveSites->view()->selectionModel(), &QItemSelectionModel::selectionChanged, this, &DiveSiteListView::selectionChanged);
|
2019-03-13 20:56:41 +00:00
|
|
|
|
|
|
|
|
// Subtle: We depend on this slot being executed after the slot in the model.
|
|
|
|
|
// This is realized because the model was constructed as a member object and connects in the constructor.
|
2022-09-18 11:49:29 +00:00
|
|
|
connect(&diveListNotifier, &DiveListNotifier::diveSiteChanged, this, &DiveSiteListView::diveSiteChanged);
|
2019-03-09 21:32:16 +00:00
|
|
|
}
|
|
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
void DiveSiteListView::done()
|
2019-03-09 21:32:16 +00:00
|
|
|
{
|
2022-09-18 13:25:41 +00:00
|
|
|
MainWindow::instance()->enterPreviousState();
|
2019-03-09 21:32:16 +00:00
|
|
|
}
|
2019-03-13 19:58:25 +00:00
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
void DiveSiteListView::diveSiteClicked(const QModelIndex &index)
|
2019-11-02 21:52:27 +00:00
|
|
|
{
|
desktop: fix saving of column-widths of device and site tables
Qt's memory management scheme is completely broken and messes
with common expectations.
QObjects are organized as a tree. The children are destroyed
in the destructor of QObject. This means that they are destructed
after the destructor of the parent object has run and its
sub-object were destructed. Obviously, this makes no sense as
the child objects should be able to access their parent at
any time.
To restore the commonly expected deterministic order of
construction and destruction, one might simply do away with
Qt's silly object tree and organise things using classical
subobjects. However, that breaks with the Qt-generated UI
classes: The objects generated by these classes are *not*
destructed with the UI class. Instead, they are attached
to the widget's QObject tree. Thus these are again destructed
*after* the widget! Who comes up with such a scheme?
In our case this means that we cannot have models used for
TableViews as subobjects, because the TableView needs the
model to save the column widths in the destructor. Which,
as detailed above is called *after* the desctructor of the
widget! Thus, turn these models into heap-allocated objects
and add them to the QObject tree.
Funilly, this exposes another insanity of Qt's QObject tree:
Children are destructed in order of construction! One would
expect that if objects are constructed in the sequence
A, B, C one can expect that C can, at any time, access B and A.
Not so in Qt: The destruction order is likewise A, B, C!
Thus, take care to init the widgets before the model. Jeez.
Finally, print a warning in the column-saving code of
TableWidget, so that these kind of subtleties are caught
in the future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-11-07 12:20:46 +00:00
|
|
|
struct dive_site *ds = model->getDiveSite(index);
|
2019-11-02 21:52:27 +00:00
|
|
|
if (!ds)
|
|
|
|
|
return;
|
|
|
|
|
switch (index.column()) {
|
|
|
|
|
case LocationInformationModel::EDIT:
|
|
|
|
|
MainWindow::instance()->editDiveSite(ds);
|
|
|
|
|
break;
|
|
|
|
|
case LocationInformationModel::REMOVE:
|
|
|
|
|
if (ds->dives.nr > 0 &&
|
2022-09-18 11:49:29 +00:00
|
|
|
QMessageBox::warning(this, tr("Delete dive site?"),
|
2019-11-02 21:52:27 +00:00
|
|
|
tr("This dive site has %n dive(s). Do you really want to delete it?\n", "", ds->dives.nr),
|
|
|
|
|
QMessageBox::Yes|QMessageBox::No) == QMessageBox::No)
|
|
|
|
|
return;
|
|
|
|
|
Command::deleteDiveSites(QVector<dive_site *>{ds});
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
void DiveSiteListView::add()
|
2019-03-13 19:58:25 +00:00
|
|
|
{
|
2019-03-13 20:36:31 +00:00
|
|
|
// This is mighty dirty: We hook into the "dive site added" signal and
|
|
|
|
|
// select the name field of the added dive site when the command sends
|
|
|
|
|
// the signal. This works only because we know that the model added the
|
|
|
|
|
// connection first. Very subtle!
|
|
|
|
|
// After the command has finished, the signal is disconnected so that dive
|
|
|
|
|
// site names are not selected on regular redo / undo.
|
2022-09-18 11:49:29 +00:00
|
|
|
connect(&diveListNotifier, &DiveListNotifier::diveSiteAdded, this, &DiveSiteListView::diveSiteAdded);
|
2019-03-13 19:58:25 +00:00
|
|
|
Command::addDiveSite(tr("New dive site"));
|
2022-09-18 11:49:29 +00:00
|
|
|
disconnect(&diveListNotifier, &DiveListNotifier::diveSiteAdded, this, &DiveSiteListView::diveSiteAdded);
|
2019-03-13 20:36:31 +00:00
|
|
|
}
|
|
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
void DiveSiteListView::diveSiteAdded(struct dive_site *, int idx)
|
2019-03-13 20:36:31 +00:00
|
|
|
{
|
|
|
|
|
if (idx < 0)
|
|
|
|
|
return;
|
|
|
|
|
QModelIndex globalIdx = LocationInformationModel::instance()->index(idx, LocationInformationModel::NAME);
|
desktop: fix saving of column-widths of device and site tables
Qt's memory management scheme is completely broken and messes
with common expectations.
QObjects are organized as a tree. The children are destroyed
in the destructor of QObject. This means that they are destructed
after the destructor of the parent object has run and its
sub-object were destructed. Obviously, this makes no sense as
the child objects should be able to access their parent at
any time.
To restore the commonly expected deterministic order of
construction and destruction, one might simply do away with
Qt's silly object tree and organise things using classical
subobjects. However, that breaks with the Qt-generated UI
classes: The objects generated by these classes are *not*
destructed with the UI class. Instead, they are attached
to the widget's QObject tree. Thus these are again destructed
*after* the widget! Who comes up with such a scheme?
In our case this means that we cannot have models used for
TableViews as subobjects, because the TableView needs the
model to save the column widths in the destructor. Which,
as detailed above is called *after* the desctructor of the
widget! Thus, turn these models into heap-allocated objects
and add them to the QObject tree.
Funilly, this exposes another insanity of Qt's QObject tree:
Children are destructed in order of construction! One would
expect that if objects are constructed in the sequence
A, B, C one can expect that C can, at any time, access B and A.
Not so in Qt: The destruction order is likewise A, B, C!
Thus, take care to init the widgets before the model. Jeez.
Finally, print a warning in the column-saving code of
TableWidget, so that these kind of subtleties are caught
in the future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-11-07 12:20:46 +00:00
|
|
|
QModelIndex localIdx = model->mapFromSource(globalIdx);
|
2019-03-13 20:36:31 +00:00
|
|
|
ui.diveSites->view()->setCurrentIndex(localIdx);
|
|
|
|
|
ui.diveSites->view()->edit(localIdx);
|
2019-03-13 19:58:25 +00:00
|
|
|
}
|
2019-03-13 20:56:41 +00:00
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
void DiveSiteListView::diveSiteChanged(struct dive_site *ds, int field)
|
2019-03-13 20:56:41 +00:00
|
|
|
{
|
core: introduce divelog structure
The parser API was very annoying, as a number of tables
to-be-filled were passed in as pointers. The goal of this
commit is to collect all these tables in a single struct.
This should make it (more or less) clear what is actually
written into the divelog files.
Moreover, it should now be rather easy to search for
instances, where the global logfile is accessed (and it
turns out that there are many!).
The divelog struct does not contain the tables as substructs,
but only collects pointers. The idea is that the "divelog.h"
file can be included without all the other files describing
the numerous tables.
To make it easier to use from C++ parts of the code, the
struct implements a constructor and a destructor. Sadly,
we can't use smart pointers, since the pointers are accessed
from C code. Therfore the constructor and destructor are
quite complex.
The whole commit is large, but was mostly an automatic
conversion.
One oddity of note: the divelog structure also contains
the "autogroup" flag, since that is saved in the divelog.
This actually fixes a bug: Before, when importing dives
from a different log, the autogroup flag was overwritten.
This was probably not intended and does not happen anymore.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2022-11-08 20:31:08 +00:00
|
|
|
int idx = get_divesite_idx(ds, divelog.sites);
|
2019-03-13 20:56:41 +00:00
|
|
|
if (idx < 0)
|
|
|
|
|
return;
|
|
|
|
|
QModelIndex globalIdx = LocationInformationModel::instance()->index(idx, field);
|
desktop: fix saving of column-widths of device and site tables
Qt's memory management scheme is completely broken and messes
with common expectations.
QObjects are organized as a tree. The children are destroyed
in the destructor of QObject. This means that they are destructed
after the destructor of the parent object has run and its
sub-object were destructed. Obviously, this makes no sense as
the child objects should be able to access their parent at
any time.
To restore the commonly expected deterministic order of
construction and destruction, one might simply do away with
Qt's silly object tree and organise things using classical
subobjects. However, that breaks with the Qt-generated UI
classes: The objects generated by these classes are *not*
destructed with the UI class. Instead, they are attached
to the widget's QObject tree. Thus these are again destructed
*after* the widget! Who comes up with such a scheme?
In our case this means that we cannot have models used for
TableViews as subobjects, because the TableView needs the
model to save the column widths in the destructor. Which,
as detailed above is called *after* the desctructor of the
widget! Thus, turn these models into heap-allocated objects
and add them to the QObject tree.
Funilly, this exposes another insanity of Qt's QObject tree:
Children are destructed in order of construction! One would
expect that if objects are constructed in the sequence
A, B, C one can expect that C can, at any time, access B and A.
Not so in Qt: The destruction order is likewise A, B, C!
Thus, take care to init the widgets before the model. Jeez.
Finally, print a warning in the column-saving code of
TableWidget, so that these kind of subtleties are caught
in the future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-11-07 12:20:46 +00:00
|
|
|
QModelIndex localIdx = model->mapFromSource(globalIdx);
|
2019-03-13 20:56:41 +00:00
|
|
|
ui.diveSites->view()->scrollTo(localIdx);
|
|
|
|
|
}
|
2019-03-19 18:52:54 +00:00
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
void DiveSiteListView::on_purgeUnused_clicked()
|
2019-03-19 18:52:54 +00:00
|
|
|
{
|
|
|
|
|
Command::purgeUnusedDiveSites();
|
|
|
|
|
}
|
2019-03-24 16:11:29 +00:00
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
void DiveSiteListView::on_filterText_textChanged(const QString &text)
|
2019-03-24 16:11:29 +00:00
|
|
|
{
|
desktop: fix saving of column-widths of device and site tables
Qt's memory management scheme is completely broken and messes
with common expectations.
QObjects are organized as a tree. The children are destroyed
in the destructor of QObject. This means that they are destructed
after the destructor of the parent object has run and its
sub-object were destructed. Obviously, this makes no sense as
the child objects should be able to access their parent at
any time.
To restore the commonly expected deterministic order of
construction and destruction, one might simply do away with
Qt's silly object tree and organise things using classical
subobjects. However, that breaks with the Qt-generated UI
classes: The objects generated by these classes are *not*
destructed with the UI class. Instead, they are attached
to the widget's QObject tree. Thus these are again destructed
*after* the widget! Who comes up with such a scheme?
In our case this means that we cannot have models used for
TableViews as subobjects, because the TableView needs the
model to save the column widths in the destructor. Which,
as detailed above is called *after* the desctructor of the
widget! Thus, turn these models into heap-allocated objects
and add them to the QObject tree.
Funilly, this exposes another insanity of Qt's QObject tree:
Children are destructed in order of construction! One would
expect that if objects are constructed in the sequence
A, B, C one can expect that C can, at any time, access B and A.
Not so in Qt: The destruction order is likewise A, B, C!
Thus, take care to init the widgets before the model. Jeez.
Finally, print a warning in the column-saving code of
TableWidget, so that these kind of subtleties are caught
in the future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-11-07 12:20:46 +00:00
|
|
|
model->setFilter(text);
|
2019-03-24 16:11:29 +00:00
|
|
|
}
|
2019-04-12 14:12:15 +00:00
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
QVector<dive_site *> DiveSiteListView::selectedDiveSites()
|
2019-04-12 14:12:15 +00:00
|
|
|
{
|
2020-03-11 10:30:51 +00:00
|
|
|
const QModelIndexList indices = ui.diveSites->view()->selectionModel()->selectedRows();
|
2019-04-12 14:12:15 +00:00
|
|
|
QVector<dive_site *> sites;
|
2020-03-11 10:30:51 +00:00
|
|
|
sites.reserve(indices.size());
|
|
|
|
|
for (const QModelIndex &idx: indices) {
|
desktop: fix saving of column-widths of device and site tables
Qt's memory management scheme is completely broken and messes
with common expectations.
QObjects are organized as a tree. The children are destroyed
in the destructor of QObject. This means that they are destructed
after the destructor of the parent object has run and its
sub-object were destructed. Obviously, this makes no sense as
the child objects should be able to access their parent at
any time.
To restore the commonly expected deterministic order of
construction and destruction, one might simply do away with
Qt's silly object tree and organise things using classical
subobjects. However, that breaks with the Qt-generated UI
classes: The objects generated by these classes are *not*
destructed with the UI class. Instead, they are attached
to the widget's QObject tree. Thus these are again destructed
*after* the widget! Who comes up with such a scheme?
In our case this means that we cannot have models used for
TableViews as subobjects, because the TableView needs the
model to save the column widths in the destructor. Which,
as detailed above is called *after* the desctructor of the
widget! Thus, turn these models into heap-allocated objects
and add them to the QObject tree.
Funilly, this exposes another insanity of Qt's QObject tree:
Children are destructed in order of construction! One would
expect that if objects are constructed in the sequence
A, B, C one can expect that C can, at any time, access B and A.
Not so in Qt: The destruction order is likewise A, B, C!
Thus, take care to init the widgets before the model. Jeez.
Finally, print a warning in the column-saving code of
TableWidget, so that these kind of subtleties are caught
in the future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2020-11-07 12:20:46 +00:00
|
|
|
struct dive_site *ds = model->getDiveSite(idx);
|
2019-04-12 14:12:15 +00:00
|
|
|
sites.append(ds);
|
|
|
|
|
}
|
2019-05-05 10:18:04 +00:00
|
|
|
return sites;
|
|
|
|
|
}
|
|
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
void DiveSiteListView::selectionChanged(const QItemSelection &, const QItemSelection &)
|
2019-04-12 14:12:15 +00:00
|
|
|
{
|
2019-11-17 17:13:55 +00:00
|
|
|
DiveFilter::instance()->setFilterDiveSite(selectedDiveSites());
|
2019-04-12 14:12:15 +00:00
|
|
|
}
|
|
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
void DiveSiteListView::hideEvent(QHideEvent *)
|
2019-04-12 14:12:15 +00:00
|
|
|
{
|
|
|
|
|
// If the user switches to the dive site tab and there was already a selection,
|
|
|
|
|
// filter on that selection.
|
2022-09-18 11:49:29 +00:00
|
|
|
DiveFilter::instance()->stopFilterDiveSites();
|
2019-04-12 14:12:15 +00:00
|
|
|
}
|
|
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
void DiveSiteListView::showEvent(QShowEvent *)
|
2019-04-12 14:12:15 +00:00
|
|
|
{
|
2022-09-18 11:49:29 +00:00
|
|
|
// If the user switches to the dive site tab and there was already a selection,
|
|
|
|
|
// filter on that selection.
|
|
|
|
|
DiveFilter::instance()->startFilterDiveSites(selectedDiveSites());
|
2019-04-12 14:12:15 +00:00
|
|
|
}
|
