2019-03-09 21:32:16 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2022-09-18 11:49:29 +00:00
|
|
|
#ifndef DIVE_SITE_LIST_VIEW_H
|
|
|
|
|
#define DIVE_SITE_LIST_VIEW_H
|
2019-03-09 21:32:16 +00:00
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
#include "ui_divesitelistview.h"
|
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
|
|
|
|
|
|
|
|
class DiveSiteSortedModel;
|
2019-03-09 21:32:16 +00:00
|
|
|
|
2022-09-18 11:49:29 +00:00
|
|
|
class DiveSiteListView : public QWidget {
|
2019-03-09 21:32:16 +00:00
|
|
|
Q_OBJECT
|
|
|
|
|
public:
|
2022-09-18 11:49:29 +00:00
|
|
|
DiveSiteListView(QWidget *parent = 0);
|
2019-03-13 19:58:25 +00:00
|
|
|
private slots:
|
|
|
|
|
void add();
|
2022-09-18 11:49:29 +00:00
|
|
|
void done();
|
2019-03-13 20:36:31 +00:00
|
|
|
void diveSiteAdded(struct dive_site *, int idx);
|
2019-03-13 20:56:41 +00:00
|
|
|
void diveSiteChanged(struct dive_site *ds, int field);
|
2019-11-02 21:52:27 +00:00
|
|
|
void diveSiteClicked(const QModelIndex &);
|
2019-03-19 18:52:54 +00:00
|
|
|
void on_purgeUnused_clicked();
|
2019-03-24 16:11:29 +00:00
|
|
|
void on_filterText_textChanged(const QString &text);
|
2019-04-12 14:12:15 +00:00
|
|
|
void selectionChanged(const QItemSelection &selected, const QItemSelection &deselected);
|
2019-03-09 21:32:16 +00:00
|
|
|
private:
|
2022-09-18 11:49:29 +00:00
|
|
|
Ui::DiveSiteListView ui;
|
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
|
|
|
DiveSiteSortedModel *model;
|
2019-05-05 10:18:04 +00:00
|
|
|
QVector<dive_site *> selectedDiveSites();
|
2019-04-12 14:12:15 +00:00
|
|
|
void hideEvent(QHideEvent *) override;
|
|
|
|
|
void showEvent(QShowEvent *) override;
|
2019-03-09 21:32:16 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif
|