subsurface/desktop-widgets/divesitelistview.cpp

148 lines
5.3 KiB
C++
Raw Permalink Normal View History

// SPDX-License-Identifier: GPL-2.0
#include "divesitelistview.h"
#include "core/subsurface-qt/divelistnotifier.h"
#include "core/divelog.h"
#include "core/divesite.h"
#include "core/divefilter.h"
#include "qt-models/divelocationmodel.h"
#include "desktop-widgets/mainwindow.h"
#include "commands/command.h"
#include <QMessageBox>
DiveSiteListView::DiveSiteListView(QWidget *parent) : QWidget(parent)
{
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
// 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);
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);
// Default: sort by name
ui.diveSites->view()->sortByColumn(LocationInformationModel::NAME, Qt::AscendingOrder);
ui.diveSites->view()->setSortingEnabled(true);
ui.diveSites->view()->horizontalHeader()->setSectionResizeMode(LocationInformationModel::NAME, QHeaderView::Stretch);
ui.diveSites->view()->horizontalHeader()->setSectionResizeMode(LocationInformationModel::DESCRIPTION, QHeaderView::Stretch);
ui.diveSites->view()->setSelectionBehavior(QAbstractItemView::SelectRows);
// Show only the first few columns
for (int i = LocationInformationModel::LOCATION; i < LocationInformationModel::COLUMNS; ++i)
ui.diveSites->view()->setColumnHidden(i, true);
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);
// 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.
connect(&diveListNotifier, &DiveListNotifier::diveSiteChanged, this, &DiveSiteListView::diveSiteChanged);
}
void DiveSiteListView::done()
{
MainWindow::instance()->enterPreviousState();
}
void DiveSiteListView::diveSiteClicked(const QModelIndex &index)
{
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);
if (!ds)
return;
switch (index.column()) {
case LocationInformationModel::EDIT:
MainWindow::instance()->editDiveSite(ds);
break;
case LocationInformationModel::REMOVE:
if (!ds->dives.empty() &&
QMessageBox::warning(this, tr("Delete dive site?"),
tr("This dive site has %n dive(s). Do you really want to delete it?\n", "", ds->dives.size()),
QMessageBox::Yes|QMessageBox::No) == QMessageBox::No)
return;
Command::deleteDiveSites(QVector<dive_site *>{ds});
break;
}
}
void DiveSiteListView::add()
{
// 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.
connect(&diveListNotifier, &DiveListNotifier::diveSiteAdded, this, &DiveSiteListView::diveSiteAdded);
Command::addDiveSite(tr("New dive site"));
disconnect(&diveListNotifier, &DiveListNotifier::diveSiteAdded, this, &DiveSiteListView::diveSiteAdded);
}
void DiveSiteListView::diveSiteAdded(struct dive_site *, int idx)
{
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);
ui.diveSites->view()->setCurrentIndex(localIdx);
ui.diveSites->view()->edit(localIdx);
}
void DiveSiteListView::diveSiteChanged(struct dive_site *ds, int field)
{
size_t idx = divelog.sites.get_idx(ds);
if (idx == std::string::npos)
return;
QModelIndex globalIdx = LocationInformationModel::instance()->index(static_cast<int>(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);
ui.diveSites->view()->scrollTo(localIdx);
}
void DiveSiteListView::on_purgeUnused_clicked()
{
Command::purgeUnusedDiveSites();
}
void DiveSiteListView::on_filterText_textChanged(const QString &text)
{
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);
}
std::vector<dive_site *> DiveSiteListView::selectedDiveSites()
{
const QModelIndexList indices = ui.diveSites->view()->selectionModel()->selectedRows();
std::vector<dive_site *> sites;
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);
sites.push_back(ds);
}
return sites;
}
void DiveSiteListView::selectionChanged(const QItemSelection &, const QItemSelection &)
{
DiveFilter::instance()->setFilterDiveSite(selectedDiveSites());
}
void DiveSiteListView::hideEvent(QHideEvent *)
{
// If the user switches to the dive site tab and there was already a selection,
// filter on that selection.
DiveFilter::instance()->stopFilterDiveSites();
}
void DiveSiteListView::showEvent(QShowEvent *)
{
// If the user switches to the dive site tab and there was already a selection,
// filter on that selection.
DiveFilter::instance()->startFilterDiveSites(selectedDiveSites());
}