RecentRequestsTableModel
instancing to where it’s needed which in turn breaks the circular dependency between WalletModel
and RecentRequestsTableModel
.
RecentRequestsTableModel
instancing to where it’s needed which in turn breaks the circular dependency between WalletModel
and RecentRequestsTableModel
.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
69@@ -70,15 +70,17 @@ void ReceiveCoinsDialog::setModel(WalletModel *_model)
70
71 if(_model && _model->getOptionsModel())
72 {
73- _model->getRecentRequestsTableModel()->sort(RecentRequestsTableModel::Date, Qt::DescendingOrder);
74+ assert(m_recent_requests_table_model == nullptr);
75+ m_recent_requests_table_model = new RecentRequestsTableModel(_model);
delete
necessary in this case? I tend to prefer it occur even if not strictly necessary.
setModel(nullptr)
?
No
delete
necessary in this case?
m_recent_requests_table_model
is a QObject
with a parent. This ensures that it will be deleted during its parent deletion, no?
Yes. Only thing “wrong” is that when WalletModel
is destroyed we will have a dangling
m_recent_requests_table_model
. But AFAICT this shouldn’t be a concern because that happens when the wallet is being unloaded and everything is being destroyed.
Anyway, I’m thinking we could move away from these setModel(WalletModel*)
and pass it on the constructor, but it’s going to take a while to get there.
Only thing “wrong” is that when
WalletModel
is destroyed we will have a danglingm_recent_requests_table_model
.
Sounds not good…
But AFAICT this shouldn’t be a concern because that happens when the wallet is being unloaded and everything is being destroyed.
Agree.
Anyway, I’m thinking we could move away from these
setModel(WalletModel*)
and pass it on the constructor, but it’s going to take a while to get there.
Maybe discuss this on IRC meeting?
Maybe discuss this on IRC meeting?
Not sure worth it, a draft PR with the whole change might be better.
This will create a new RecentRequestsTableModel
every time setModel
is called. I do not think this is expected behavior. setModel
should set a model not create one.
Maybe pass it in from the caller?
This is called once, see the assertion above.
There is no use case for switching models, that’s why I think we can slowly refactor to get the dependencies on the constructor rather than having these setters, which add unnecessary state management.
211@@ -212,7 +212,7 @@ void TestGUI(interfaces::Node& node)
212 // Check Request Payment button
213 ReceiveCoinsDialog receiveCoinsDialog(platformStyle.get());
214 receiveCoinsDialog.setModel(&walletModel);
215- RecentRequestsTableModel* requestTableModel = walletModel.getRecentRequestsTableModel();
216+ auto requestTableModel = MakeUnique<RecentRequestsTableModel>(&walletModel);
receiveCoinsDialog.m_recent_requests_table_model
.. will fix.
211@@ -212,7 +212,8 @@ void TestGUI(interfaces::Node& node)
212 // Check Request Payment button
213 ReceiveCoinsDialog receiveCoinsDialog(platformStyle.get());
214 receiveCoinsDialog.setModel(&walletModel);
215- RecentRequestsTableModel* requestTableModel = walletModel.getRecentRequestsTableModel();
216+ auto requestTableModel = receiveCoinsDialog.recentRequestsTableModel();
RecentRequestsTableModel*
remains.
Also using auto
for simple types seems overkill ;)
test_bitcoin-qt
, have passed.
auto
.
44@@ -44,6 +45,8 @@ class ReceiveCoinsDialog : public QDialog
45
46 void setModel(WalletModel *model);
47
48+ RecentRequestsTableModel* recentRequestsTableModel() const { return m_recent_requests_table_model; }
nit: seems like returning a const
pointer would be more correct, given that this is a const method
Perhaps negligible as this is only used in the test, it has no other impact:
0diff --git a/src/qt/receivecoinsdialog.h b/src/qt/receivecoinsdialog.h
1index e400129f7..5dc340aed 100644
2--- a/src/qt/receivecoinsdialog.h
3+++ b/src/qt/receivecoinsdialog.h
4@@ -45,7 +45,7 @@ public:
5
6 void setModel(WalletModel *model);
7
8- RecentRequestsTableModel* recentRequestsTableModel() const { return m_recent_requests_table_model; }
9+ const RecentRequestsTableModel* recentRequestsTableModel() const { return m_recent_requests_table_model; }
10
11 public Q_SLOTS:
12 void clear();
13diff --git a/src/qt/test/wallettests.cpp b/src/qt/test/wallettests.cpp
14index c15b1c0d6..276df75f4 100644
15--- a/src/qt/test/wallettests.cpp
16+++ b/src/qt/test/wallettests.cpp
17@@ -212,7 +212,7 @@ void TestGUI(interfaces::Node& node)
18 // Check Request Payment button
19 ReceiveCoinsDialog receiveCoinsDialog(platformStyle.get());
20 receiveCoinsDialog.setModel(&walletModel);
21- RecentRequestsTableModel* requestTableModel = receiveCoinsDialog.recentRequestsTableModel();
22+ const RecentRequestsTableModel* requestTableModel = receiveCoinsDialog.recentRequestsTableModel();
23 assert(requestTableModel);
24
25 // Label input
nit: seems like returning a
const
pointer would be more correct, given that this is a const method
More correct why? Those are orthogonal.
Well, not in every case, but in many cases it would be incongruent if an instance was const and its member was not - for example, if I have a const
counter object, but I exposed the current count in an externally modifiable way, then that would be incongruent IMO.
In this case, it’s not necessary to expose members in a non-const way from a const method, so I would bias toward the more restrictive presentation.
setModel
actually creating the model, or conceptually, a dialog creating its own model (for that matter). But if everyone else is ok with it’s fine…