Drop wildcard support for address/label search in AddressBookPage

[hebasto]

Wildcard support for address/label search in AddressBookPage was introduced in bitcoin/bitcoin#12080, and it is available in release binaries since v0.17.

But this feature has never being documented or mentioned in the GUI.

Thus, there are no reasons to believe that users rely on this feature.

Required for migration to Qt 6, because:

There is no direct way to do wildcard matching in QRegularExpression.

Tests included.

Based on #591, so only last 2 commits belong to this PR.

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #593 (Getting ready to Qt 6 (8/n). Use QRegularExpression in AddressBookSortFilterProxyModel class by hebasto)
• #585 (Replace QRegExp with QRegularExpression by prusnak)

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.

[luke-jr]

cc @promag

[luke-jr]

"However, the wildcardToRegularExpression method is provided to translate glob patterns into a Perl-compatible regular expression that can be used for that purpose."

Seems like it should be trivial to retain this feature, if we want to?

[laanwj]

~0 on this. As I've said on IRC I don't particularly care for this feature to go (I don't think the entire Address Book is particularly useful, searching in the Transactions tab should cover it?), though "being compatible with Qt 6" is a strange motivation. As @luke-jr says it would still be possible by rewriting the expression.

[hebasto]

Rebased on top of the merged #591.

[hebasto]

@luke-jr

"However, the wildcardToRegularExpression method is provided to translate glob patterns into a Perl-compatible regular expression that can be used for that purpose."

Seems like it should be trivial to retain this feature, if we want to?

Would you mind provide a working example please?

[promag]

Tested ACK 555b673.

TBH I didn't think about using a wildcard in the search field, so setFilterFixedString would be sufficient.

The only issue I have is breaking someone's expectation, as this is a breaking change - using wildcard results in an empty list where before it could list some addresses. I understand it's not documented but it's available for some time. Maybe could validate the search field to disallow wildcard, like:

yle, Mode _mode,
 {
     ui->setupUi(this);

+    auto validator = new QRegularExpressionValidator(QRegularExpression("[^\\*]*"), this);
+    ui->searchLineEdit->setValidator(validator);
+
     if (!platformStyle->getImagesOnButtons()) {
         ui->newAddress->setIcon(QIcon());
         ui->copyAddress->setIcon(QIcon());

Finally, if we stick to supporting wildcard then no changes are required as explained in the comment below (but didn't test with Qt6).

[promag]

In fact setFilterWildcard in Qt6 already handles the change noted in the porting documentation:

There is no direct way to do wildcard matching in QRegularExpression. However, the wildcardToRegularExpression method is provided to translate glob patterns into a Perl-compatible regular expression that can be used for that purpose.

Qt5

void QSortFilterProxyModel::setFilterFixedString(const QString &pattern)
{
    Q_D(QSortFilterProxyModel);
    d->filter_about_to_be_changed();
    QRegExp rx(pattern, d->filter_data.caseSensitivity(), QRegExp::FixedString);
    d->filter_data.setRegExp(rx);
    d->filter_changed();
}

Qt6

void QSortFilterProxyModel::setFilterWildcard(const QString &pattern)
{
    Q_D(QSortFilterProxyModel);
    d->filter_regularexpression.removeBindingUnlessInWrapper();
    d->filter_about_to_be_changed();
    d->set_filter_pattern(QRegularExpression::wildcardToRegularExpression(
            pattern, QRegularExpression::UnanchoredWildcardConversion));
    d->filter_changed(QSortFilterProxyModelPrivate::Direction::Rows);
    d->filter_regularexpression.notify();
}

[hebasto]

#593 (comment)

[hebasto]

Combined into #593.