subsurface/desktop-widgets/tableview.cpp

164 lines
4.9 KiB
C++
Raw Permalink Normal View History

// SPDX-License-Identifier: GPL-2.0
#include "desktop-widgets/tableview.h"
#include "desktop-widgets/modeldelegates.h"
#include <QPushButton>
#include <QSettings>
TableView::TableView(QWidget *parent) : QGroupBox(parent)
{
ui.setupUi(this);
ui.tableView->setItemDelegate(new DiveListDelegate(this));
connect(ui.tableView, &QTableView::clicked, this, &TableView::itemClicked);
QFontMetrics fm(defaultModelFont());
int text_ht = fm.height();
metrics.icon = &defaultIconMetrics();
metrics.rm_col_width = metrics.icon->sz_small + 2*metrics.icon->spacing;
metrics.header_ht = text_ht + 10; // TODO DPI
/* We want to get rid of the margin around the table, but
* we must be careful with some styles (e.g. GTK+) where the top
* margin is actually used to hold the label. We thus check the
* rectangles for the label and contents to make sure they do not
* overlap, and adjust the top contentsMargin accordingly
*/
// start by setting all the margins at zero
QMargins margins;
// grab the label and contents dimensions and positions
QStyleOptionGroupBox option;
initStyleOption(&option);
QRect labelRect = style()->subControlRect(QStyle::CC_GroupBox, &option, QStyle::SC_GroupBoxLabel, this);
QRect contentsRect = style()->subControlRect(QStyle::CC_GroupBox, &option, QStyle::SC_GroupBoxContents, this);
/* we need to ensure that the bottom of the label is higher
* than the top of the contents */
int delta = contentsRect.top() - labelRect.bottom();
const int min_gap = metrics.icon->spacing;
if (delta <= min_gap) {
margins.setTop(min_gap - delta);
}
layout()->setContentsMargins(margins);
QIcon plusIcon(":list-add-icon");
plusBtn = new QPushButton(plusIcon, QString(), this);
plusBtn->setFlat(true);
/* now determine the icon and button size. Since the button will be
* placed in the label, make sure that we do not overflow, as it might
* get clipped
*/
int iconSize = metrics.icon->sz_small;
int btnSize = iconSize + 2*min_gap;
if (btnSize > labelRect.height()) {
btnSize = labelRect.height();
iconSize = btnSize - 2*min_gap;
}
plusBtn->setIconSize(QSize(iconSize, iconSize));
#if QT_VERSION < QT_VERSION_CHECK(5, 15, 0)
// with Qt 5.15, this leads to an inoperable button
plusBtn->resize(btnSize, btnSize);
#endif
connect(plusBtn, SIGNAL(clicked(bool)), this, SIGNAL(addButtonClicked()));
}
TableView::~TableView()
{
QSettings s;
s.beginGroup(objectName());
// remove the old default
bool oldDefault = (ui.tableView->columnWidth(0) == 30);
for (int i = 1; oldDefault && ui.tableView->model() && i < ui.tableView->model()->columnCount(); i++) {
if (ui.tableView->columnWidth(i) != 80)
oldDefault = false;
}
if (oldDefault) {
s.remove("");
} else if (ui.tableView->model()) {
for (int i = 0; i < ui.tableView->model()->columnCount(); i++) {
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
if (ui.tableView->columnWidth(i) == defaultColumnWidth(i)) {
s.remove(QString("colwidth%1").arg(i));
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
} else {
s.setValue(QString("colwidth%1").arg(i), ui.tableView->columnWidth(i));
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
}
}
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
} else {
qWarning("TableView %s without model", qPrintable(objectName()));
}
s.endGroup();
}
void TableView::setBtnToolTip(const QString &tooltip)
{
plusBtn->setToolTip(tooltip);
}
void TableView::setModel(QAbstractItemModel *model)
{
ui.tableView->setModel(model);
QSettings s;
s.beginGroup(objectName());
const int columnCount = ui.tableView->model()->columnCount();
for (int i = 0; i < columnCount; i++) {
QVariant width = s.value(QString("colwidth%1").arg(i), defaultColumnWidth(i));
ui.tableView->setColumnWidth(i, width.toInt());
}
s.endGroup();
ui.tableView->horizontalHeader()->setMinimumHeight(metrics.header_ht);
}
void TableView::fixPlusPosition()
{
QStyleOptionGroupBox option;
initStyleOption(&option);
QRect labelRect = style()->subControlRect(QStyle::CC_GroupBox, &option, QStyle::SC_GroupBoxLabel, this);
QRect contentsRect = style()->subControlRect(QStyle::CC_GroupBox, &option, QStyle::QStyle::SC_GroupBoxFrame, this);
plusBtn->setGeometry( contentsRect.width() - plusBtn->width(), labelRect.y(), plusBtn->width(), labelRect.height());
}
// We need to manually position the 'plus' on cylinder and weight.
void TableView::resizeEvent(QResizeEvent *event)
{
fixPlusPosition();
QWidget::resizeEvent(event);
}
void TableView::showEvent(QShowEvent *event)
{
QWidget::showEvent(event);
fixPlusPosition();
}
void TableView::edit(const QModelIndex &index)
{
ui.tableView->edit(index);
}
int TableView::defaultColumnWidth(int col)
{
int width;
QString text = ui.tableView->model()->headerData(col, Qt::Horizontal).toString();
#if QT_VERSION < QT_VERSION_CHECK(5, 11, 0)
int textSpace = defaultModelFontMetrics().width(text) + 4;
#else // QT 5.11 or newer
int textSpace = defaultModelFontMetrics().horizontalAdvance(text) + 4;
#endif
width = text.isEmpty() ? metrics.rm_col_width : textSpace + 4; // add small margin
#if defined(Q_OS_MAC)
width += 10; // Mac needs more margin
#endif
return width;
}
QTableView *TableView::view()
{
return ui.tableView;
}