Developer Notes for Qt Code

Contents

1. Git Tips
2. Backward Compatibility
3. QObject Subclassing Style
4. Debugging Tips

Git Tips

The GUI repo and the main Bitcoin Core repo share the same commit history. If you are going to contribute, including reviewing, to both of the repo, it is recommended to have them locally.

GUI Repo Setup

1. Log in GitHub (in command examples the GitHub username "satoshi" used), open the GUI repo, and fork it.

2. Clone the repo locally:

$ git clone https://github.com/bitcoin-core/gui.git && cd gui

3. Set up your forked repo as a local git remote:

$ git remote add satoshi https://github.com/satoshi/gui.git
$ git config remote.pushDefault satoshi

The current result could be verified:

$ git remote -v
origin	https://github.com/bitcoin-core/gui.git (fetch)
origin	https://github.com/bitcoin-core/gui.git (push)
satoshi	https://github.com/satoshi/gui.git (fetch)
satoshi	https://github.com/satoshi/gui.git (push)

4. To synchronize (any time you want) your local and forked repos:

$ git switch master
$ git pull --ff-only
$ git push

Note: Just after cloning repos are already synchronized.

Pull Request Reviewing

The recommended way to review a pull request (PR) is do it locally because it allows you to build binaries and test them. In command examples PR 42 is used.

Fetch PR branch to the local repo:

$ git fetch origin pull/42/head:pr42.01 && git switch pr42.01

It is useful to use separated local branches for every fetching. Optionally, branch names could include a sequence number (as in example above) or a convenient date/time presentation.

When a PR author updates her branch, it is easy to check the changes:

$ git diff pr42.03 pr42.04

Even if a PR branch was rebased, it is still easy to check the changes:

$ git range-diff master pr42.03 pr42.04

Note: Git branches are cheap to create and destroy.

After PR merging, all of the review branches could be removed:

$ git switch master
$ git branch -D $(git branch | grep pr42)

Backward Compatibility

The source code must be compatible with the minimum required Qt version which is set in configure.ac:

BITCOIN_QT_CONFIGURE([5.9.5])

If an optional feature requires a higher version of Qt, or if a feature was replaced by another one, use the QT_VERSION and QT_VERSION_CHECK macros:

#include <QDate>
#include <QDateTime>
#include <QtGlobal>  // For QT_VERSION and QT_VERSION_CHECK macros.

QDateTime StartOfDay(const QDate& date)
{
#if (QT_VERSION >= QT_VERSION_CHECK(5, 14, 0))
    return date.startOfDay();  // QDate::startOfDay was introduced in Qt 5.14.0.
#else
    return {date};
#endif
}

Do not compare versions of QT_VERSION directly using 0xMMNNPP (MM = major, NN = minor, PP = patch), as this approach is less readable and more error-prone.

Every time the minimum required Qt version is bumped, grep or git grep for all of the QT_VERSION instances and adjust/remove them accordingly.

QObject Subclassing Style

When sublassing the QObject class follow the pattern below:

#include <QObject>

class MyWidget : public QObject
{
    Q_OBJECT

public:
    // Public members.

public Q_SLOTS:
    // Public slots.

Q_SIGNALS:
    // Signals (inherently public).

private:
    // Private members.

private Q_SLOTS:
    // Private slots.
};

Use the Q_SIGNALS and Q_SLOTS macros instead of the signals and slots keywords of the Qt moc (Meta-Object Compiler). This prevents potential conflicts with 3rd party signal/slot mechanisms.

Debugging Tips

For debugging, including signal-to-slot connection issues, you can use the QT_FATAL_WARNINGS environment variable:

$ QT_FATAL_WARNINGS=1 src/qt/bitcoin-qt -printtoconsole -debug=qt

This tip can be combined with a debugger.

---

More notes come soon...