DEV Community: Misinahaiya

[Qt] VIII. Smart Memory Managements

Misinahaiya — Sat, 01 Mar 2025 03:52:14 +0000

"Pointers are simple creatures. They were just like ions: if you make them be in somewhere, they'll be in somewhere, and that's it.

Me

I think you'll be frustrated if you see the following messages:

It might be the result of some kind of weird runtime logic errors. Quoting Beginning C++23 by Mr. Ivor Horton and Mr. Peter Van Weert at Apress™ publishers verbatim (legal disclaimer: not for commercial use! Just for educational and tutorial purposes only),

Dangling pointer is a pointer variable that still contains the address to free store memory that has already been deallocated by either delete or delete[]. Dereferencing a dangling pointer makes you read from or, often worse, write to memory that might already be allocated to and used by other parts of your program, resulting in all kinds of unpredictable and unexpected results.

Now, I assume that you all guys have been tortured by dangling pointers and null pointers, right? The Standard gives some solutions, such as include the <memory> and using the std::unique_ptr and std::shared_ptr, etc. But, (personally,) I do not really like the design: they are complicated in definitions, the errors like Implicit template instantiation emerge everywhere, and I am not into class names with any underscores (this is just a style; but, man, we're doing C++, not Pascal, provided that even Python suggests you doing class names without underscores)

You may of course blame me for being to fastidious, I accept it by a hundred and twenty percent. But that's me. I am not satisfied. I must find a better alternative.

To master this topic, we must first know what is the C++ philosophy regarding resources allocations, or even better, how every mainstream compiler works under the hood. So, as mentioned by the creator of C++, Bjarne Stroustrup, C++ advocates allocating objects in the constructors of an object, and freeing objects in the destructors of such object. This is commonly known as RAII (Resource Acquisition Is Initialization). Given that there are no garbage collectors in C++ that would automatically release unused objects, we programmers must be very careful on checking tediously the memory leaks (i.e. in simple English, memory wastage). Will there be a better solution?

Fortunately, Qt (in many and at most time) just stood there as a life-savior. The munificent developers meticulously crafted classes such as QPointer, QSharedPointer, QWeakPointer, etc. Let us dive into them now, in this article.

If you ask me the reason why I cover this topic, is that I just mentioned the pointers and memory managements of the Qt framework several times in the past articles. They're somewhat important, but they're not as crucial a topic to be covered as the dynamic properties (that the uncovered yet mentioned features when introducing the meta-object systems). However, as a continuation to learn the meta-object system, I eventually found out that you would prefer it if you learned the smart pointers and did a good practice on them.

`QPointer`

Close analogy: std::auto_ptr

A typical template class QPointer is responsible for supervising the pointers of QObject (and its derivatives, of course). You could use it as an absolutely ordinary C/C++ pointer using the operator ->, and also you could access the pointer's meta information via the . operator and the methods with self-explanatory names like QPointer<T>::clear, QPointer<T>::data, QPointer<T>::swap and QPointer<T>::isNull, etc.

Particularly the method QPointer<T>::isNull checks that if the supervised QObject instance is usable. Under that circumstance, the method will return true. Otherwise, it will return false and the QPointer's data will automatically be 0.

The magic happens when QPointer overrode operators like *, /, -, >, !=, etc.

Practicality and usages

If you kept a primitive C++ pointer to an object of any type and when the pointer is deleted (that it would become a raw pointer), if you accessed it, a segmentation fault error would arise (as shown in the above picture). Instead, you found out that it is more convenient and practical to use the QPointer class (or other Qt-made memory managements classes). Here's a small example:

    // ...
    QPointer<QLabel> label = new QLabel("Testing");
    // ... (may be destructive operations to the label object)
    if (label)
        label->show();

In the above example, remember not to add an asterisk after the QLabel lexeme (as in QPointer<QLabel*>, which is wrong and produces a QLabl** class).

Also, the label is automatically converted to bool, which is approximately similar to determining the accessibility of an ordinary and primitive C++ pointer, except that the former one uses Qt code-bases and use smarter methods (for example, the above code will be converted to if ((!label.isNull()) && (label != 0))), while the latter one just check if the pointer is equal to 0x0 or not, which might not be effective in checking dangling pointers.

`QSharedPointer`

Close analogy: std::shared_ptr

There's an even more meticulous class called QSharedPointer<T>.

It uses reference counting internally, i.e. (for beginners) if the object belonging to QSharedPointer<T> was being deleted, provided that no other objects referenced it (i.e. its reference count was 0), then such object (which was pointed by the pointer) was deleted.

Warning: If you gave a pointer to QSharedPointer<T>, do not pass it as an argument directly as a QSharedPointer<T> (e.g. given the code Obj*obj=new Obj; QSharedPointer<Obj> objPtr(obj); void func(QSharedPointer<Obj>&), do call func(objPtr) instead of func(obj)). Also, do not delete the pointer elsewhere throughout your codebase. Do not.

For the reason why, as you might have already figured out, is that this would cause the reference counting system to moan. Given that it could not handle deletion of primitive pointers using the primitive delete operator elsewhere, the reference counting system hence omitted the existence of such code. Then, accessing it might cause SIGSEGV (as you all have been... well, I never rub salt into the wound).

Instead, you could use the = operator to copy a QSharedPointer<T> type to another, and they both shared the same pointer. This time, the internal reference counting will be correctly increased by 1, and Qt could assure that you're pointer-safe and never encounter any SIGSEGV (as you... well, well).

Practicality and usages

If you do not want to care about when and where your object will be deleted (in the meantime you hope that it will not be deleted), and the accomplish the garbage collection feature, use QSharedPointer<T>. Here's a simple example, and I just need a main.cpp file with <QtCore> only:

#include <QDebug>
#include <QSharedPointer>

class Debugger
{
public:
    Debugger()
    {
        qDebug() << "Debugger constructor called.";
        qDebug() << "";
    }

    ~Debugger()
    {
        qDebug() << "Debugger destructor called.";
        qDebug() << "";
    }

public:
    void debug(const QString &message)
    {
        qDebug() << "Debugger debugged called:";
        qDebug() << "    " << message;
    }
};

class ImportantObject
{
public:
    ImportantObject(QString name)
        : m_name(name)
    {}

    ~ImportantObject()
    {
        m_debugger->debug(QString("%1 exit").arg(m_name));
    }

public:
    void setDebugger(QSharedPointer<Debugger> &debugger)
    {
        m_debugger = debugger;
    }

private:
    QString m_name;
    QSharedPointer<Debugger> m_debugger;
};

int main(int argc, char *argv[])
{
    // Scopes:
    //     Think like functions, where the variables are not usable outside of it
    //     Sometimes called closures
    ImportantObject *obj1 = new ImportantObject("Important Object I");
    {
        QSharedPointer<Debugger> debugger(new Debugger);
        {
            QSharedPointer<Debugger> copiedDebugger(debugger);
        }

        obj1->setDebugger(debugger);

        {
            ImportantObject obj2("Important Object II");
            obj2.setDebugger(debugger);
        }
    }

    delete obj1;
    return 0;
}

Here's the result:

Debugger constructor called.

Debugger debugged called:
     "Important Object II exit"
Debugger debugged called:
     "Important Object I exit"
Debugger destructor called.

It is evident that the memory is automatically managed.

`QWeakPointer`

Close analogy: std::weak_ptr

Everyone does not want to be weak, except for memory management. A weak pointer is weak, because you could not access the pointer directly (only possible through QWeakPointer<T>::data); it is not guaranteed to be safe to access the pointer (i.e. there are chances that the referenced pointer was already deleted).

QWeakPointer<T> was largely identical to QPointer<T>, except that it could not use solely, and it must be paired up with QSharedPointer<T>. Also, though it could be converted to an equivalent QSharedPointer<T> object through QWeakPointer<T>::toStrongRef, it is too inconvenient that you still need to check if the upgraded QSharedPointer<T> object is null or not.

If it is that troublesome, why some of us still opt to use it?

That's approximately equal to the relationship of std::string_view and std::string. In the former one, you could not assign, modify, twist and bend the string. You could only view it. However, some of us still opt to use it because it's faster, as the indexing and modification processes are largely omitted. There's a similar analogy between a tuple and a list in Python.

Practicality and usages

It's speedy and satisfactory enough if we only need an observer to see if the object is null or not, rather than doing something to it.

So, here's a modified example from the example above, incorporating QSharedPointer<T> and QWeakPointer<T>:

#include <QDebug>
#include <QSharedPointer>

class Debugger
{
public:
    Debugger()
    {
        qDebug() << "Debugger constructor called.";
        qDebug() << "";
    }

    ~Debugger()
    {
        qDebug() << "Debugger destructor called.";
        qDebug() << "";
    }

public:
    void debug(const QString &message)
    {
        qDebug() << "Debugger debugged called:";
        qDebug() << "    " << message;
        qDebug() << "";
    }
};

class ImportantObject
{
public:
    ImportantObject(QString name)
        : m_name(name)
    {}

    ~ImportantObject()
    {
        m_debugger->debug(QString("%1 exit").arg(m_name));
    }

public:
    void setDebugger(QSharedPointer<Debugger> &debugger)
    {
        m_debugger = debugger;
    }

private:
    QString m_name;
    QSharedPointer<Debugger> m_debugger;
};

int main(int argc, char *argv[])
{
    // Scopes:
    //     Think like functions, where the variables are not usable outside of it
    //     Sometimes called closures
    ImportantObject *obj1 = new ImportantObject("Important Object I");
    {
        QSharedPointer<Debugger> debugger(new Debugger);
        QWeakPointer<Debugger> weakReference(debugger);

        if (!weakReference.isNull())
            qDebug() << "At I: Weak reference is not null\n";

        {
            QSharedPointer<Debugger> copiedDebugger(debugger);
            weakReference = copiedDebugger;
        }

        obj1->setDebugger(debugger);

        {
            ImportantObject obj2("Important Object II");
            obj2.setDebugger(debugger);
        }

        if (!weakReference.isNull())
            qDebug() << "At II: Weak reference is not null\n";
    }

    delete obj1;
    return 0;
}

Here's the result:

Debugger constructor called.

At I: Weak reference is not null

Debugger debugged called:
     "Important Object II exit"

At II: Weak reference is not null

Debugger debugged called:
     "Important Object I exit"

Debugger destructor called.

`QScopedPointer`

Close analogy: std::unique_ptr

QScopedPointer<T> uses the operator new to dynamically allocate objects on the stack, and it assures that at any time the dynamically created objects could be deleted successfully.

If you give the ownership of a certain object to QScopedPointer<T>, retrieve it back is not possible. Also, it never transfers ownership to any other object or smart pointer.

Note that you could even assign the method of deletion during construction.

There are four built-in allocation helpers provided by QScopedPointer, namely:

QScopedPointerDeleter uses delete and new to allocate objects;
QScopedPointerArrayDeleter uses delete[] and new[] to allocate objects;
QScopedPointerPodDeleter (where Pod means "Plain Old Data") uses C's (that's why it's plain and old) free and malloc to allocate objects; and
QScopedPointerDeleteLater uses QObject::deleteLater to delete objects wisely. Note that (presumably) it raises error on scoped pointers of non-QObject-descendant.

They could be used like (from the official Qt manual):

QScopedPointer<int, QScopedPointerArrayDeleter<int> > arrayPointer(new int[42]);

QScopedPointer<int, QScopedPointerPodDeleter> podPointer(reinterpret_cast<int *>(malloc(42)));

I said built-in, because the mighty Qt framework even allows you to create your own allocation helpers:

struct ScopedPointerCustomDeleter
{
    static inline void cleanup(MyCustomClass *pointer)
    {
        myCustomDeallocator(pointer);
    }
};

QScopedPointer<MyCustomClass, ScopedPointerCustomDeleter> customPointer(new MyCustomClass);

... Where there must be a method static public inline void cleanup(TargetClass *pointer) ~~(Not Java though!)~~

Practicality and usage

If you had many control statements that were way too complex, you might want to use a QScopedPointer<T>:

int function(Enum enum)
{
    QScopedPointer<Class> myClass = new Class;
    switch (enum)
    {
    case 1:
        if (function1(myClass))
        {
            if (externalProcess(myClass))
                return finalProcess(myClass);
            else if (anotherProcess(myClass))
                return 42;
            else if (someFunction(myClass))
                return -1;
            errorProcess(myClass);
            return 0;
        }

        else
        {
            return (yetAnother(myClass) ? 1 : 0);
        }
        break;
    case 2:
        externalProcess(myClass); break;
    default:
        return yetAnotherProcessOtherThanThose(myClass);
    }
    errorProcess(myClass);
    return -42;
}

If you do not use QScopedPointer<T>, it would be a mess.

`QObject`

QObject is sometimes considered as also a half smart pointer. It's because that QObject shows partial memory managements, but it hardly demonstrated as mighty management methods as of QScopedPointer<T> or QSharedPointer<T>, etc.

You have already seen many QObject descendants having the following parameter at their constructors:

Constructor(QObject *parent = nullptr)

As an addendum to the "Hello, World!" example, let me now elucidate why setting the parent object transfers the ownership of itself to its parent, and also when the parent got destroyed, it also got destroyed.

Here's the complete destructor of The Base Class:

/*!
    Destroys the object, deleting all its child objects.

    All signals to and from the object are automatically disconnected, and
    any pending posted events for the object are removed from the event
    queue. However, it is often safer to use deleteLater() rather than
    deleting a QObject subclass directly.

    \warning All child objects are deleted. If any of these objects
    are on the stack or global, sooner or later your program will
    crash. We do not recommend holding pointers to child objects from
    outside the parent. If you still do, the destroyed() signal gives
    you an opportunity to detect when an object is destroyed.

    \warning Deleting a QObject while it is handling an event
    delivered to it can cause a crash. You must not delete the QObject
    directly if it exists in a different thread than the one currently
    executing. Use deleteLater() instead, which will cause the event
    loop to delete the object after all pending events have been
    delivered to it.

    \sa deleteLater()
*/

QObject::~QObject()
{
    Q_D(QObject);
    d->wasDeleted = true;
    d->blockSig = 0; // unblock signals so we always emit destroyed()

    if (!d->bindingStorage.isValid()) {
        // this might be the case after an incomplete thread-move
        // remove this object from the pending list in that case
        if (QThread *ownThread = thread()) {
            auto *privThread = static_cast<QThreadPrivate *>(
                        QObjectPrivate::get(ownThread));
            privThread->removeObjectWithPendingBindingStatusChange(this);
        }
    }

    // If we reached this point, we need to clear the binding data
    // as the corresponding properties are no longer useful
    d->clearBindingStorage();

    QtSharedPointer::ExternalRefCountData *sharedRefcount = d->sharedRefcount.loadRelaxed();
    if (sharedRefcount) {
        if (sharedRefcount->strongref.loadRelaxed() > 0) {
            qWarning("QObject: shared QObject was deleted directly. The program is malformed and may crash.");
            // but continue deleting, it's too late to stop anyway
        }

        // indicate to all QWeakPointers that this QObject has now been deleted
        sharedRefcount->strongref.storeRelaxed(0);
        if (!sharedRefcount->weakref.deref())
            delete sharedRefcount;
    }

    if (!d->wasWidget && d->isSignalConnected(0)) {
        emit destroyed(this);
    }

    if (!d->isDeletingChildren && d->declarativeData && QAbstractDeclarativeData::destroyed)
        QAbstractDeclarativeData::destroyed(d->declarativeData, this);

    QObjectPrivate::ConnectionData *cd = d->connections.loadAcquire();
    if (cd) {
        if (cd->currentSender) {
            cd->currentSender->receiverDeleted();
            cd->currentSender = nullptr;
        }

        QBasicMutex *signalSlotMutex = signalSlotLock(this);
        QMutexLocker locker(signalSlotMutex);

        // disconnect all receivers
        int receiverCount = cd->signalVectorCount();
        for (int signal = -1; signal < receiverCount; ++signal) {
            QObjectPrivate::ConnectionList &connectionList = cd->connectionsForSignal(signal);

            while (QObjectPrivate::Connection *c = connectionList.first.loadRelaxed()) {
                Q_ASSERT(c->receiver.loadAcquire());

                QBasicMutex *m = signalSlotLock(c->receiver.loadRelaxed());
                bool needToUnlock = QOrderedMutexLocker::relock(signalSlotMutex, m);
                if (c == connectionList.first.loadAcquire() && c->receiver.loadAcquire()) {
                    cd->removeConnection(c);
                    Q_ASSERT(connectionList.first.loadRelaxed() != c);
                }
                if (needToUnlock)
                    m->unlock();
            }
        }

        /* Disconnect all senders:
         */
        while (QObjectPrivate::Connection *node = cd->senders) {
            Q_ASSERT(node->receiver.loadAcquire());
            QObject *sender = node->sender;
            // Send disconnectNotify before removing the connection from sender's connection list.
            // This ensures any eventual destructor of sender will block on getting receiver's lock
            // and not finish until we release it.
            sender->disconnectNotify(QMetaObjectPrivate::signal(sender->metaObject(), node->signal_index));
            QBasicMutex *m = signalSlotLock(sender);
            bool needToUnlock = QOrderedMutexLocker::relock(signalSlotMutex, m);
            //the node has maybe been removed while the mutex was unlocked in relock?
            if (node != cd->senders) {
                // We hold the wrong mutex
                Q_ASSERT(needToUnlock);
                m->unlock();
                continue;
            }

            QObjectPrivate::ConnectionData *senderData = sender->d_func()->connections.loadRelaxed();
            Q_ASSERT(senderData);

            QtPrivate::QSlotObjectBase *slotObj = nullptr;
            if (node->isSlotObject) {
                slotObj = node->slotObj;
                node->isSlotObject = false;
            }

            senderData->removeConnection(node);
            /*
              When we unlock, another thread has the chance to delete/modify sender data.
              Thus we need to call cleanOrphanedConnections before unlocking. We use the
              variant of the function which assumes that the lock is already held to avoid
              a deadlock.
              We need to hold m, the sender lock. Considering that we might execute arbitrary user
              code, we should already release the signalSlotMutex here – unless they are the same.
            */
            const bool locksAreTheSame = signalSlotMutex == m;
            if (!locksAreTheSame)
                locker.unlock();
            senderData->cleanOrphanedConnections(
                        sender,
                        QObjectPrivate::ConnectionData::AlreadyLockedAndTemporarilyReleasingLock
                        );
            if (needToUnlock)
                m->unlock();

            if (locksAreTheSame) // otherwise already unlocked
                locker.unlock();
            if (slotObj)
                slotObj->destroyIfLastRef();
            locker.relock();
        }

        // invalidate all connections on the object and make sure
        // activate() will skip them
        cd->currentConnectionId.storeRelaxed(0);
    }
    if (cd && !cd->ref.deref())
        delete cd;
    d->connections.storeRelaxed(nullptr);

    if (!d->children.isEmpty())
        d->deleteChildren();

    if (Q_UNLIKELY(qtHookData[QHooks::RemoveQObject]))
        reinterpret_cast<QHooks::RemoveQObjectCallback>(qtHookData[QHooks::RemoveQObject])(this);

    Q_TRACE(QObject_dtor, this);

    if (d->parent)        // remove it from parent object
        d->setParent_helper(nullptr);
}

In simple English, there are five crucial steps:

Dereferenciation of the QWeakPointer<T> weak references;
Emit the signal QObject::destroyed;
Disconnect all signal-slots connections established;
Delete the children; and
Remove itself from the parent object.

So, if we have a class that could automatically manages such processes, it will be much more convenient. The class should supervise as much QObject as possible just like QPointer<T>, and it could demonstrate automatic memory managements just like QScopedPointer<T>.

Introducing: QObjectCleanupHandler.

You could use QObjectCleanupHandler::add to add object, isEmpty to determine if there is still living QObject's, and you could also clear all objects using QObjectCleanupHandler::clear.

Practicality and usage

I would normally make this class a resource manager, and I suggest you doing so as well. If you have multiple QObject's that are roughly identical, you use QObjectCleanupHandler. Personally, I think that this one is useful.

Here's a minimalistic example:

void SomethingsManager::run()
{
    Manager *m1 = new Manager(this);
    // ...
    // ...
    QObjectCleanupHandler cleanup;
    cleanup.add(m1);
    cleanup.add(m2);
    // ...

    exec();
}

Do take a break and refer to some C++ docs in order to grasp the concept of std::unique_ptr and std::shared_ptr, etc.

[Qt] VII. Multi-threads Signals and Slots

Misinahaiya — Tue, 25 Feb 2025 11:22:46 +0000

"Multitasking is a part of my everyday life."

Monica Denise Brown

I could feel your brain's absolute pain of binge-eating those information last article. To simplify things, before getting into the topic, I provide some useful tips in using signals:

A signal can connect to a slot;
A slot can receive more than one signal;
A signal can connect to more than one slot;
Number and types of parameters in signals and slots must match, otherwise errors occur;
The number of parameters of the slot could be less than the number of the signal's, but not more than.
The connection between signals and slots is dynamic, i.e. executed in runtime.
Signals could connect to another signal, but slots could not connect to another slot.

For the reason why, you could refer to my previous article and use a bit of your logic.

Prerequisites

For complete novices at threading and concurrency (sometimes multitasking/ multi-processing), you could just consider the smallest unit of threading - threads - as different processes running at the same time.

In Qt, there are many thread-safe functions and methods. The term thread-safety means that the variables and members always maintain a valid state, i.e. they're not interfered.

A situation where thread-safety does not exist:

There's an integer variable, say, a, initialized as 20.
Thread 1 changes it to 30.
Thread 2 uses it to calculate something, and process the result.

This looks all fine. But what if, say:

...
Thread 1 changes it to 30.
Thread 3 accidentally changes it to 0.
Thread 2 uses it to calculate something, which is expected as 30 but got 0.

If Thread 2 is processing an internal event or process, that is still fine; at most a segmentation fault or zero-division error will occur and the application will crash. However, if Thread 2 is handling, say, OS-wide event or system-related or critical processes, then your computer will screw up. Say, if you're using your computer for an important reason, your whole day will be bad, I guess.

From here, you could see how important thread safety is.

Connection Types

I've introduced the basic signal connection syntax:

connect(signalObject, signal, slotObject, slot);

Actually, there's a hidden Qt::ConnectionType connectionType behind. It defaults to Qt::ConnectionType::AutoConnection.

Here's the enumerators:

Qt::ConnectionType::AutoConnection: The default one of the QObject::connect (as just mentioned). If the signal and slot are on the same thread (you'll get to know what does it mean), it becomes Qt::ConnectionType::DirectConnection. Else, it becomes Qt::ConnectionType::QueuedConnection.
Qt::ConnectionType::DirectConnection: As the name suggests, when the signal emits, the slot will be called instantly. This is not thread-safe (as mentioned).
Qt::ConnectionType::QueuedConnection: The slot will not be called instantly after the signal emits. Instead, a private class (i.e. an internal class used by Qt itself only, you could not normally access it) called QMetaCallEvent is sent to the receiver. It is an event (wait for and see the later articles). The slot is executed in the receiver's thread.
Qt::ConnectionType::BlockingQueuedConnection: Same as Qt::ConnectionType::QueuedConnection, but the signalling thread blocks until the slot returns. You should not use this one in a single-threaded application, or else your application will become unresponsive ~~(But who on earth will modify these settings manually!?)~~

For queued connections, the thread is actually called by QApplication::postEvent(). This explains that why it usually calls the slot inside the thread that the object of the slot currently lives in.

Also, for queued connections, I suggest you explicitly pointing out to the compiler that you're using queued connections, as it makes the code more readable and reduces error occurrences (well, probably).

There are two flags added so that you could use the a bitwise OR operator (|) to combine them with the above connection types.

Qt::ConnectionType::UniqueConnection: Ensures the uniqueness of the connection, i.e. QObject::connect will fail if the same signal has already been connected to the same slot of the same pair of objects.
Qt::ConnectionType::SingleShotConnection: Ensures the singleness of the emission, i.e. emit-ing the signal will not work if the signal has already been emitted once. That is, the connection will be automatically broken after the signal is emitted.

Do remember that you could actually use QObject::sender to access the sender of the signal; yet this violates the design patterns of OOP (object-oriented programming). In addition, there are few points to know in using sender():

Its return type is QObject; you need to use qobject_cast to convert it to the desired type (wait and see the article introducing the dynamic system of Qt).
An invalid pointer is returned when your function/ method scope is not a signal (well, fair enough. How on earth could you ask your fish how many Spanish words he or she knows?)
An invalid pointer is returned when your slot does not live in the same thread as the sender (well, still fair enough. How could you possibly send a message to some random aliens that live 8000 light years away? By telepathy?)

Well, it's wetter than the theories and explanations of the previous article, but it's still very dry. So, I'll craft yet another mini-example showcasing the mighty trans-thread communication system of the signal-slot mechanism of the meta-object system of the module <QtCore> of Qt!

Little Example

There's a little, simple and intuitive app, say - the corresponding project is titled as "Countdown10Seconds" - which counts down 10 seconds commencing from the start of the app (to be precise, it is the time when the thread receives the start-counting signal; and to be even more precise, the term "signal" I have just used has nothing to do with the "signal" as in signal-slot connections). There is a label showing you the thread information, remaining seconds, etc. After the timeout, there will be a newline appended to the label's text, which read "10 seconds have passed."

We have to create 2 classes (i.e. 4 files using the language spoken by Qt Creator), SecondObject and CountThread.

Without further ado, as my usual practice, I will show you my code and explain as detailed as possible.

secondobject.h:

#ifndef SECONDOBJECT_H
#define SECONDOBJECT_H

#include <QObject>

class SecondObject : public QObject
{
    Q_OBJECT

public:
    explicit SecondObject(int seconds, QObject *parent = nullptr);

signals:
    void secondPassed(int seconds, unsigned long long identifier);

public slots:
    void onTimeout();

private:
    int m_seconds;
};

#endif // SECONDOBJECT_H

secondobject.cpp:

#include "secondobject.h"

#include <QThread>


SecondObject::SecondObject(int seconds, QObject *parent)
    : QObject(parent),
    m_seconds(seconds)
{}

void SecondObject::onTimeout()
{
    if (m_seconds >= 0)
    {
        unsigned long long identifier = (unsigned long long)QThread::currentThreadId();
        emit secondPassed(m_seconds, identifier);
        --m_seconds;
    }

    else
    {
        QThread::currentThread()->exit(0);
    }
}

countthread.h:

#ifndef COUNTTHREAD_H
#define COUNTTHREAD_H

#include <QThread>
#include <QPointer>

class MainWindow;

class CountThread : public QThread
{
    Q_OBJECT

public:
    CountThread(MainWindow *parent);
    ~CountThread(){}

protected:
    void run() override;

private:
    QPointer<MainWindow> m_parent;
};

#endif // COUNTTHREAD_H

countthread.cpp:

#include "countthread.h"
#include "secondobject.h"
#include "mainwindow.h"

#include <QTimer>


CountThread::CountThread(MainWindow *parent)
    : m_parent(parent)
{}

void CountThread::run()
{
    QTimer timer;
    SecondObject secondObject(10); // 10 seconds
    connect(&timer,
            &QTimer::timeout,
            &secondObject,
            &SecondObject::onTimeout);
    timer.start(1000); // 1000 milliseconds, discussed already earlier

    if (!m_parent.isNull())
        connect(&secondObject,
                &SecondObject::secondPassed,
                m_parent.data(),
                &MainWindow::onSecondLeft);

    exec();
}

mainwindow.h:

#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <QMainWindow>
#include <QLabel>

class MainWindow : public QMainWindow
{
    Q_OBJECT

public:
    MainWindow(QWidget *parent = nullptr);
    ~MainWindow();

public slots:
    void onSecondLeft(int seconds, unsigned long long identifier);

private:
    QLabel *m_label;
};
#endif // MAINWINDOW_H

mainwindow.cpp:

#include "mainwindow.h"
#include "countthread.h"

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
{
    m_label = new QLabel(this);
    m_label->setAlignment(Qt::AlignmentFlag::AlignCenter);
    m_label->setMargin(25);
    setCentralWidget(m_label);
    setWindowTitle("Misinahaiya - Multi-thread Signals");

    CountThread *thread = new CountThread(this);
    connect(thread,
            &CountThread::finished,
            thread,
            &CountThread::deleteLater);
    thread->start();
}

MainWindow::~MainWindow()
{}

void MainWindow::onSecondLeft(int seconds, unsigned long long identifier)
{
    QString string = QString("There is/are %1 second(s) left, and the current (executing) thread identifier is %2.\n"
                             "The second-counting thread's identifier is %3.")
            .arg(seconds).arg((unsigned long long)QThread::currentThreadId()).arg(identifier);
    if (seconds == 0)
        string.append("\n10 seconds have passed.");
    m_label->setText(string);
}

main.cpp:

#include "mainwindow.h"

#include <QApplication>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    MainWindow w;
    w.show();
    return a.exec();
}

Results

Here are the two tiny images showcasing the results of our tiny ~~ and useless~~ application:

Not yet been timeout:
Timeout already:

Explanations

Analyzing the headers, we could see that the SecondObject::secondPassed signal will be emitted every second.

The counting thread inherits QThread as you could see, and QThread is the most basic threading class in Qt (somehow canonical too, you will be introduced later after you have mastered the use of Qt GUI and Qt Widgets).

To make use of the QThread::start method and send signals efficiently, I overrode the virtual method QThread::run. As the candle wick (the initiator, sorry for the bewilderment if you do not understand my metaphor) of a QThread is typically QThread::start, and it calls its underlying protected method QThread::run, overriding it is a good way to prevent reinventing the wheel.

As the thread is considered useless after it exited in this case (i.e. the program guarantees that the thread will not be reused), so it's safe to delete this on finishing calling the method exit(0) (where "0" symbolizes no errors occurred, same as the Unix return codes). However, to really ensure no one is using the thread anymore, I have introduced a new method QObject::deleteLater to you. It schedules the removal of the unwanted object, i.e. the mighty Qt (meta-) object system has an intricate and meticulous way to ensure nothing is using the object anymore before the removal. If you're interested, please go and look at some docs that are better than mine.

On introducing the QObject::deleteLater slot, I think I also need to introduce a completely new class to you QPointer. Have you ever used smart pointers? If yes, then it's pretty simple and similar in nature. If you haven't (oh my, are you a C programmer from the 90's?), then I'll explain it in few sentences in simple English: a smart pointer is a pointer that automatically detects the deletion of the linked object. As a pointer is a reference that is pointing to an object by definition, it's just a bunch of binary numbers. So, if you have a pointer pointing to 0 (no object) or nullptr, it's a null pointer; to a deleted object, it's a dangling pointer; to an invalid object, it's a raw pointer. You do not need to memorize these terms, as it is not the main point. You just need to know that there's a magical class in Qt, QPointer, where it overrides the operators . and -> so that you could access meta-pointer information (like if it is deleted, null etc.) and the pointer itself.

So, the above example is a practical usage of not only QThread and QObject::connect, but also QPointer!

One last thing is QString. It's a Qt string class. We will discuss this more deeply in the following topics, covering the basic types of Qt like containers (lists, arrays, maps, etc.) and strings (chars, strings, byte arrays, etc.)

The entry function main is generated by Qt Creator and it's very typical. So I'll not dive deep into it as I've already explained it.

For convenience and conciseness, Qt::ConnectionType::QueuedConnection is not used. However, for actual practice, I do suggest you adding it explicitly, but I wouldn't urge you to do so as, really, it does not matter, for the QObject::connect method will automatically detect so.

Conclusion

Right, so this chapter is considered as a little addendum to the previous ultra-long article. I know that explaining and putting bunch of examples regarding the feature-rich signal-slot system in one fell swoop would make you faint, so I'll split it into the single-threaded worked-examples (the previous one) and the multi-threaded worked-example (this one).

Anyway, hopefully you got what signals really do. At least you could (almost) master the signal-slot system in Qt, and it's about 70% in terms of the weighing of the importance of the Qt meta-object system.

In the next article or two, I'll be introducing the rest of the meta-object system features. Still that line, stayed tuned to this series and practice your Qt skill constantly!

[Qt] VI. Signals-slots and Meta-objects

Misinahaiya — Mon, 24 Feb 2025 06:48:02 +0000

"In fact, the socialization (connection) gives us the tools to fill our evolutionary roles. They are our building blocks."

Warren Farrell

Yes, socialization is so important to us humans who are all characterized as gregarious animals million years ago. Something created by humans could not be an exception as well (... well, there are still plenty of exceptions though having said that). In fact, the socialization system of Qt among classes under QObject, canonically known as the signal-slot(s) connection, is worth explaining it using two or three five-thousand-word pieces of prose.

Why? Because it's the heart of various Qt objects - it is the fact the most efficient, standardized, well-known and (probably) the only way to communicate between objects (including widgets and a whole bunch more that will be introduced later).

Let us dive - hopefully as deep as possible - into the well-known signal-slot system, and the controller behind: the meta-object system.

(In fact, I have already mentioned two or three times in my previous articles. They're too important that even a hello-world example for fresh novices requires so.)

The Heart's Heart of Heart

If you peek at the official repositories of (open-source) Qt, you will soon discovered that the one with the most traffic, stars and popularity by looking at the number of forks (provided that you are using GitHub), and the most important one by inferring the name, is Qt Base. Of the ten or twenty sub-components of the Qt Base repository, by just inferring their names, you will figure out that Qt Core is the most important one. In Qt Core, the signal-slot system is the most important one.

That is why it is called the heart's heart of heart.

Qt could somehow be considered as a library based on the signal-slot system, or more accurately, the meta-object system. The meta-object system, in plain English, is a mechanism used to build independent software components (you will soon get to know what I mean). These components need not to recognize (identify) each other at runtime, even in order to run and collaborate with one another seamlessly. After this article and probably two or three more, you will soon discover that the meta-object system extends the C++ language per se and beautifies it, given that you follow my steps and learn Qt patiently for a while.

Why? Because the meta-object system provides 3 key features:

Signal-slot system (it's way too important that it sometimes be the pronoun of the meta-object system per se though it's just a part of it; we'll be using the term "meta-object system" consistently from now on in this series. Sorry for the previous incongruousness),
Dynamic runtime-data-type detection (do you believe it, It's C-plus-plus plus Qt, not Python nor Ruby! How mighty is Qt), and
Dynamic property system.

Everything in Qt is possible if and only if these 3 key features is possible and got implemented.

In this article, we'll talk about the first one first. In the next or two, I'll be cover the rest of them.

The meta-object system is possible when

The class inherits QObject or any of its subclass, i.e. the class that would like to enjoy the meta-object system must be, either direct or indirect, descendant of QObject. This is because the meta-object system is implemented by QObject and QMetaObject (you'll get to know it later in this article).
As the meta-object system requires some private class members, so every QObject descendant needs to get a Q_OBJECT macro declared in the private: section of the class (owing the fact that C++ defaults members of undeclared accessibility as private members, so you could also put the macro as the first declaration of the class, which is consistent with the Qt programming style, as well as mine). Putting it in the public: section is an undefined behavior (at least I have never tried it). If you do not do so, errors regarding undefined members will be raised if you try to define a signal, emit a signal (see later) in or with this class (internally and externally respectively); similarly, if you do so in a non-QObject-descendant class, you'll still get a whole bunch of errors as the declaration calls some QObject methods.
You must have a meta-object compiler made by Qt. It's somehow like the preprocessor compiler mandated by the C++ Standard and provided by almost all C/C++ compilers. However, instead of dealing with the hash signs #, it deals with the Q_OBJECT declarations, implementing the dynamic properties, etc. Unless you accidentally delete it (I won't believe there is such a careless person in the world), this condition is the easiest to fulfill by the time you finished the Qt installation.

The above content looks so dry that I think we need a comprehensive and self-explanatory example to make it practical.

Flowers

This time, we only build a console project. To build a console project (i.e. the project that you do not use a window or something, just use the core features of Qt), you will follow the following steps:

Launch Qt Creator (of course!)
Click File -> New Project as always
Then, here's the different part: after the dialog is being launched, do manually click the "Qt Console Application" instead of the default one, "Qt Widget Application".
Follow the steps in the "Hello, Qt!" article. Name your project a reasonable title, and for this time, I opt for "Flowers" instead of any other strange things.

If you're curious, you could glimpse at the newly created CMakeLists.txt file, and it differs from the previous files at: all Widget entries are replaced by the word Core. That indicates that using widgets is invalid and may results in a preprocessing error or a linkage error (for C++ intermediate learners, just think of some errors irrelevant to your code). But since we're using the meta-object system today, using the cores is already enough.

Using the <QtCore> module is indeed already enough, but only having the main.cpp file is indeed not enough. To set things up, we need to create four additional files, namely flower.h, flower.cpp, picker.h and picker.cpp. We could just create them by pressing the hotkey (Ctrl+N) or navigating to the action File -> New File (I've already taught it before in somewhere, haven't I), then choose the option "C++ Class".

Enter the name of the class. After entering the name, you could soon realize that the "Header file:" and "Source file:" fields are already filled of their required relative directories automatically by Qt Creator. How helpful it is!

As the two classes, namely Flower and Picker need to inherit QObject, select the option "QObject" in the combo-box labeled as "Base class:". Qt Creator is so helpful that it automatically helps you in selecting the often-omitted options: #include <QObject> and add the macro directive Q_OBJECT. Without these two, our code cannot function. But it's the two cute (?) creatures that we often forget.

Anyways, let's press "Next" and your final dialogs should look like these ones:

Okay, let's do some coding (finally!)

The code is pretty standardized, so I will just pick some important spots to explain. The other parts are often self-explanatory. (I am trying my best to reduce your reading stress in this article as this one should be the longest one throughout the whole series; but forgive me, because the meta-object system is literally the behemoth in Qt and explaining it takes two or three longest articles like this one.)

Full code

Let me show you my code first. I'll then explain it.

flower.h:

#ifndef FLOWER_H
#define FLOWER_H

#include <QObject>
#include <QTimer>

class Flower : public QObject
{
    Q_OBJECT

public:
    explicit Flower(int secToBloom, int bloomToWither, QObject *parent = nullptr);

signals:
    void bloomSignal();
    void witherSignal();

protected slots:
    void onFlowerBloom();

private:
    QTimer *m_timer;
    int m_secToBloom;
    int m_bloomToWither;
};

#endif // FLOWER_H

flower.cpp:

#include "flower.h"


Flower::Flower(int secToBloom, int bloomToWither, QObject *parent)
    : QObject(parent),
    m_timer(new QTimer(this)),
    m_secToBloom(secToBloom * 1'000),
    m_bloomToWither(bloomToWither * 1'000)
{
    m_timer->setSingleShot(true);

    connect(m_timer,
            &QTimer::timeout,
            this,
            &Flower::onFlowerBloom);

    m_timer->start(m_secToBloom);
}

void Flower::onFlowerBloom()
{
    emit bloomSignal();

    disconnect(m_timer,
               &QTimer::timeout,
               this,
               &Flower::onFlowerBloom);

    connect(m_timer,
            &QTimer::timeout,
            this,
            &Flower::witherSignal);

    m_timer->start(m_bloomToWither);
}

picker.h:

#ifndef PICKER_H
#define PICKER_H

#include <QObject>

class Picker : public QObject
{
    Q_OBJECT

public:
    explicit Picker(QString name, QObject *parent = nullptr);

public slots:
    void onFlowerBloom();
    void onFlowerWither();

private:
    QString m_name;
};

#endif // PICKER_H

picker.cpp:

#include "picker.h"

#include <QDebug>
#include <QCoreApplication>


Picker::Picker(QString name, QObject *parent)
    : QObject(parent),
    m_name(name)
{}

void Picker::onFlowerBloom()
{
    qDebug() << "I," << m_name << ", picked a flower when it bloomed!";
}

void Picker::onFlowerWither()
{
    qDebug() << "[Sobbing] I," << m_name << ", witnessed the death of a beautiful flower. How sad!";
    QCoreApplication::exit(0);
}

From the above example, we could conclude that the basic syntax for connecting the "sender" (signal) to the "receiver" (slot) is

QObject::connect(objectSender, signalPointer, objectReceiver, slotPointer);

If you're connecting inside a QObject subclass, you may omit the member/ scope indicator QObject::.

From the above example, we also explored the three different keywords introduced by Qt: signal, slot and emit. The signal keyword introduces a list of signals in the class member declaration lists until the next access specifier meets, so does the slot: keyword. The emit keyword, followed by a signal, emits that signal.

We could see that we could connect a same signal to multiple slots (as in the Flower::bloomSignal) too.

We also explored the usage of a pretty handy class QTimer. We'll look into it later, but you just need to remember that QTimer::start starts a timer by milliseconds (that's why the private properties Flower::m_secToBloom and Flower::m_bloomToWither needs to be multiplied by 1000 programmatically in the fields-initialization list), while a timer emits the QTimer::timeout signal after the time is out. The QTimer::singleShot method specifies that the timeout signal will be emitted once only, instead of an interval of the number specified in the parameter of QTimer::start.

Also, as a good practice, unless the QObject subclass will not be referred by any other functions (i.e. passed in as a parameter), you should really use the pointer forms of the QObject's instead of the variable forms.

Additionally, you may be using some libraries such as boost, which have classes or identifiers called signals, slots or emit, i.e. the Qt identifiers clash with them. In this case, fire your CMakeLists.txt up and add the following definition:

add_definitions(-DQT_NO_KEYWORDS)

After that, you will discover that you are not able to use signals, slots and emit keywords any more. Instead, you must use Q_SIGNALS, Q_SLOTS and Q_EMIT respectively.

If these macro names still clash, well, then, the 3-rd party library designer, you're a son-of-a-b***h, go refactor your code...

Why?

As mentioned, these 6 names are all macros (7 if you count Q_OBJECT; in fact, there are hundred or more macros defined by Qt).

If you go on qobjectdefs.h in the Qt Base repository, you'll find the following code:

#define signals public __attribute__((annotate("qt_signal")))
#define slots __attribute__((annotate("qt_slot")))

Q_SIGNAL and Q_SLOTS are actually the same.

A signal is basically a waiting-to-be-handled public object, and the annotation will probably be ignored by the compiler (because it has been tagged __attribute__, see here), so does a slot.

As signals is already been defined as public while slots is not, that is the reason why the syntax public signals: is illegal while public slots: is legal. This also explains that in, say, private:signals: a();, a could still be accessed outside of the class.

Same as emit (or Q_EMIT), if you go to qmetamacros.h, you will soon discovered that

#define emit

So, emit signal(); is just signal();. Actually, when you defined the signal, the Meta-object compiler (moc or moc.exe if you're on Windows) compiles the signal into a function. That's why you could also connect a signal to another signal (connect QTimer::timeout to Flower::witherSignal above, for example).

Actually, there are also two macros you haven't been introduced yet. They are SIGNALS and SLOTS, where you'll find them on decade-old code. They're basically converting the name to a string of a name that is recognized by the moc. Precisely, in moc, "1" means a slot and "2" means a signal. If you, say, do the code SIGNAL(clicked()) and SLOT(onClicked()), they output "2clicked()" and "1onClicked()" respectively. This is why Qt Creator warns you if you have a space between the arguments as these macros require strict formatting and strict syntax.
We seldom use these directives now, and we better use the function pointer to pass to the connect function. They're outdated, obsolete and will not be used unless we need to deal with an antique, like code written fifteen years ago where Qt 5 was still in beta-testing. Until the challenges and big projects in this series later on, we'll not be using any of them.

Do notice that mix-and-match is not allowed, i.e. a function pointer connecting to a SLOT macro or vice versa.

Meta-object Compiler is a True Magician

The Q_OBJECT macro defines some key functions of performing the meta-object mechanism:

#define Q_OBJECT \
public: \
    QT_WARNING_PUSH \
    Q_OBJECT_NO_OVERRIDE_WARNING \
    static const QMetaObject staticMetaObject; \
    virtual const QMetaObject *metaObject() const; \
    virtual void *qt_metacast(const char *); \
    virtual int qt_metacall(QMetaObject::Call, int, void **); \
    QT_TR_FUNCTIONS \
private: \
    Q_OBJECT_NO_ATTRIBUTES_WARNING \
    Q_DECL_HIDDEN_STATIC_METACALL static void qt_static_metacall(QObject *, QMetaObject::Call, int, void **); \
    QT_WARNING_POP \
    QT_DEFINE_TAG_STRUCT(QPrivateSignal); \
    QT_ANNOTATE_CLASS(qt_qobject, "")

It basically:

Defines a static meta-object QMetaObject staticMetaObject,
Overrides the virtual method QObject::metaObject,
Overrides the virtual method QObject::qt_metacast,
Does some internationalization support (we'll be discussing that later),
Overrides the virtual method QObject::qt_metacall, and
Defines the static function qt_static_metacall.

For your level, you need not care what are and how do these methods work. You just need to know them they're important and indispensable so as to do some signaling works.

In C++, every declared functions that are called at least once must have a definition somewhere, otherwise you'll have the linkage error by the linker, saying the Undefined reference at somewhere (I'm pretty sure that you all have been tortured by it, haven't you). The moc compiler, in simple English, is generating the definitions of the above functions (as well as the initialization of the objects).

The files are usually named identical as the host source file with a prefix moc_ over it, for example the Flower class in flower.cpp have its meta-object definitions in moc_flower.cpp.

Let's take a closer look on the moc_flower.cpp (for moc_picker.cpp, the overall structure is about the same):

/****************************************************************************
** Meta object code from reading C++ file 'flower.h'
**
** Created by: The Qt Meta Object Compiler version 68 (Qt 6.8.1)
**
** WARNING! All changes made in this file will be lost!
*****************************************************************************/

#include "../../../../flower.h"
#include <QtCore/qmetatype.h>

#include <QtCore/qtmochelpers.h>

#include <memory>


#include <QtCore/qxptype_traits.h>
#if !defined(Q_MOC_OUTPUT_REVISION)
#error "The header file 'flower.h' doesn't include <QObject>."
#elif Q_MOC_OUTPUT_REVISION != 68
#error "This file was generated using the moc from 6.8.1. It"
#error "cannot be used with the include files from this version of Qt."
#error "(The moc has changed too much.)"
#endif

#ifndef Q_CONSTINIT
#define Q_CONSTINIT
#endif

QT_WARNING_PUSH
QT_WARNING_DISABLE_DEPRECATED
QT_WARNING_DISABLE_GCC("-Wuseless-cast")
namespace {
struct qt_meta_tag_ZN6FlowerE_t {};
} // unnamed namespace


#ifdef QT_MOC_HAS_STRINGDATA
static constexpr auto qt_meta_stringdata_ZN6FlowerE = QtMocHelpers::stringData(
    "Flower",
    "bloomSignal",
    "",
    "witherSignal",
    "onFlowerBloom"
);
#else  // !QT_MOC_HAS_STRINGDATA
#error "qtmochelpers.h not found or too old."
#endif // !QT_MOC_HAS_STRINGDATA

Q_CONSTINIT static const uint qt_meta_data_ZN6FlowerE[] = {

 // content:
      12,       // revision
       0,       // classname
       0,    0, // classinfo
       3,   14, // methods
       0,    0, // properties
       0,    0, // enums/sets
       0,    0, // constructors
       0,       // flags
       2,       // signalCount

 // signals: name, argc, parameters, tag, flags, initial metatype offsets
       1,    0,   32,    2, 0x06,    1 /* Public */,
       3,    0,   33,    2, 0x06,    2 /* Public */,

 // slots: name, argc, parameters, tag, flags, initial metatype offsets
       4,    0,   34,    2, 0x09,    3 /* Protected */,

 // signals: parameters
    QMetaType::Void,
    QMetaType::Void,

 // slots: parameters
    QMetaType::Void,

       0        // eod
};

Q_CONSTINIT const QMetaObject Flower::staticMetaObject = { {
    QMetaObject::SuperData::link<QObject::staticMetaObject>(),
    qt_meta_stringdata_ZN6FlowerE.offsetsAndSizes,
    qt_meta_data_ZN6FlowerE,
    qt_static_metacall,
    nullptr,
    qt_incomplete_metaTypeArray<qt_meta_tag_ZN6FlowerE_t,
        // Q_OBJECT / Q_GADGET
        QtPrivate::TypeAndForceComplete<Flower, std::true_type>,
        // method 'bloomSignal'
        QtPrivate::TypeAndForceComplete<void, std::false_type>,
        // method 'witherSignal'
        QtPrivate::TypeAndForceComplete<void, std::false_type>,
        // method 'onFlowerBloom'
        QtPrivate::TypeAndForceComplete<void, std::false_type>
    >,
    nullptr
} };

void Flower::qt_static_metacall(QObject *_o, QMetaObject::Call _c, int _id, void **_a)
{
    auto *_t = static_cast<Flower *>(_o);
    if (_c == QMetaObject::InvokeMetaMethod) {
        switch (_id) {
        case 0: _t->bloomSignal(); break;
        case 1: _t->witherSignal(); break;
        case 2: _t->onFlowerBloom(); break;
        default: ;
        }
    }
    if (_c == QMetaObject::IndexOfMethod) {
        int *result = reinterpret_cast<int *>(_a[0]);
        {
            using _q_method_type = void (Flower::*)();
            if (_q_method_type _q_method = &Flower::bloomSignal; *reinterpret_cast<_q_method_type *>(_a[1]) == _q_method) {
                *result = 0;
                return;
            }
        }
        {
            using _q_method_type = void (Flower::*)();
            if (_q_method_type _q_method = &Flower::witherSignal; *reinterpret_cast<_q_method_type *>(_a[1]) == _q_method) {
                *result = 1;
                return;
            }
        }
    }
}

const QMetaObject *Flower::metaObject() const
{
    return QObject::d_ptr->metaObject ? QObject::d_ptr->dynamicMetaObject() : &staticMetaObject;
}

void *Flower::qt_metacast(const char *_clname)
{
    if (!_clname) return nullptr;
    if (!strcmp(_clname, qt_meta_stringdata_ZN6FlowerE.stringdata0))
        return static_cast<void*>(this);
    return QObject::qt_metacast(_clname);
}

int Flower::qt_metacall(QMetaObject::Call _c, int _id, void **_a)
{
    _id = QObject::qt_metacall(_c, _id, _a);
    if (_id < 0)
        return _id;
    if (_c == QMetaObject::InvokeMetaMethod) {
        if (_id < 3)
            qt_static_metacall(this, _c, _id, _a);
        _id -= 3;
    }
    if (_c == QMetaObject::RegisterMethodArgumentMetaType) {
        if (_id < 3)
            *reinterpret_cast<QMetaType *>(_a[0]) = QMetaType();
        _id -= 3;
    }
    return _id;
}

// SIGNAL 0
void Flower::bloomSignal()
{
    QMetaObject::activate(this, &staticMetaObject, 0, nullptr);
}

// SIGNAL 1
void Flower::witherSignal()
{
    QMetaObject::activate(this, &staticMetaObject, 1, nullptr);
}
QT_WARNING_POP

After analyzing the source code, the moc compiler actually:

Scans the headers, and analyzes the names and the corresponding information (like slots) according to the signals: and slots: specifiers (actually by looking at the attributes "qt_signals" and "qt_slots", etc.) and stores them into a global variable qt_meta_stringdata_ succeeding the class name. The strange numbers are actually internal references used by C++ storing the data of overrides, overloads and templates (and that's why we need to have extern "C" when communicating with C code, as the nomenclature is different in nature; anyway, back to the topic),
Annotates the methods, signals, slots, properties, enumerators, etc. and stores them into the global array qt_meta_data_ succeeding by an internal class name,
Implements the declarations in Q_OBJECT. It calls some QObject functions, and that's why I have mentioned that non-QObject-descendants will have some errors in using this macro. It then initializes and puts all sort of behaviors inside the staticMetaObject instance, and links all implemented methods to the staticMetaObject instance.
Makes templates and implementations for the signals Flower::bloomSignal and Flower::witherSignal().

The signals, as in step 4, are actually regular functions:

void Flower::bloomSignal()
{
    QMetaObject::activate(this, &staticMetaObject, 0, nullptr);
}

What does the `QMetaObject::activate` do?

Connecting

QMetaObject::activate is an internal method in QMetaObject. In QMetaObject in the file qobjectdefs.h, it defines that

// internal index-based signal activation
    static void activate(QObject *sender, int signal_index, void **argv);
    static void activate(QObject *sender, const QMetaObject *, int local_signal_index, void **argv);
    static void activate(QObject *sender, int signal_offset, int local_signal_index, void **argv);

Looking deeper into the source of QMetaObject, you will soon discover that the QMetaObject is just a struct with many anonymous attributes, like:

struct Q_CORE_EXPORT QMetaObject
{
    // E L L I P S E S
    struct Data { // private data
        SuperData superdata;
        const uint *stringdata;
        const uint *data;
        typedef void (*StaticMetacallFunction)(QObject *, QMetaObject::Call, int, void **);
        StaticMetacallFunction static_metacall;
        const SuperData *relatedMetaObjects;
        const QtPrivate::QMetaTypeInterface *const *metaTypes;
        void *extradata; //reserved for future use
    } d;
    // E L L I P S E S
};

What you need to care about is that in moc_flower.cpp, the variables and instances with the prefix qt_meta_data_ members are actually transferred to the QMetaObject::d members. For example, qt_meta_stringdata_ZN6FlowerE is actually given to QMetaObject::d::stringdata; qt_meta_data_ZN6FlowerE is actually given to QMetaObject::d::data; qt_static_metacall is actually given to QMetaObject::d::static_metacall, etc.

The QMetaObject::activate, as well as the qt_static_metacall functions, are all functions calling a signal/ slot/ meta-method by an index. For example, in QMetaObject::activate, after analyzing the source code, there are actually several steps in invoking the signals:

Testing if the signals are connected, the method returns if not,
Testing the declarative data,
Testing any signal interference,
Getting the connectors,
Calling all the slots involved
Calling the additional signal interference.

These might seem a bit abstract, and for your level, you just need to know that it calls QMetaObject::metacall. The latter one tests the instance of the receiver, and if it is valid, it calls its metaCall() method; otherwise, it calls the qt_metacall() method defined in the instance of the receiver. As long as the receiver also inherits QObject, qt_metacall is guaranteed to exist.

How do I know the indices, in order to call the `activate()`, `metaCall()` or `qt_metacall()` methods?

Simple. First, the moc will just simply scan the number of signals the heir has, and it hands over to the internal class Connection, which represents a signal connection.

There are two important members in Connection, namely Connection::method_relative and Connection::method_offset. After calling the QObject::connect connection method, it hands over the signaling data to the QMetaObject class.

You do not need to know how they work; they're to be hidden and remain internal. But you just need to know that they in QMetaObject, it matches the relative index of a method (and assigns some index to a newly met method). When invoking the signals, another method methodMatch is encountered and it matches the corresponding method, like the overloading part, overriding part and any other parts.

The required data include data, static_metacall in QMetaObject::d, which are all defined in moc_flower.cpp.

This leads us to today's final topic:

`QMetaObject`

I know you're scratching your head till your brain could consume all the information we have discussed. Fortunately, today's key points could be reviewed unlimited times as long as dev.to is free. So, please allow me to introduce a hidden struct we've mentioned numerous times yet not discussed: QMetaObject.

Actually, it's simpler than the magics of moc. It's way simpler. To understand QMetaObject, think of staticMetaObject. It stores all the meta information (i.e. information related to the class per se, in plain English, like the class name, signals names and indices, slots names and indices, parent classes, properties, etc.), and it is these pieces of required information make signal-slot connection possible.

Here's some key methods in QMetaObject:

className returns the name of a class,
superClass returns the QMetaObject of parent class of the host class.
We have other name-explanatory methods like method, methodCount, enumerator, enumeratorCount, constructor, constructorCount etc. They all return some meta classes like QMetaMethod or QMetaEnum, etc., which have similar functions as a QMetaObject. Note that accessing the methods, constructors, etc. requires the index, which is described above.

For Python lovers, here's a close analogy:

>>> import inspect
>>> # It's just literally the same
>>> import pprint; pprint.pprint(dir(inspect))
['AGEN_CLOSED',
 'AGEN_CREATED',
 'AGEN_RUNNING',
 'AGEN_SUSPENDED',
 'ArgInfo',
 'Arguments',
 'Attribute',
 'BlockFinder',
 'BoundArguments',
 'BufferFlags',
 'CORO_CLOSED',
 'CORO_CREATED',
 'CORO_RUNNING',
 'CORO_SUSPENDED',
 'CO_ASYNC_GENERATOR',
 'CO_COROUTINE',
 'CO_GENERATOR',
 'CO_ITERABLE_COROUTINE',
 'CO_NESTED',
 'CO_NEWLOCALS',
 'CO_NOFREE',
 'CO_OPTIMIZED',
 'CO_VARARGS',
 'CO_VARKEYWORDS',
 'ClassFoundException',
 'ClosureVars',
 'EndOfBlock',
 'FrameInfo',
 'FullArgSpec',
 'GEN_CLOSED',
 'GEN_CREATED',
 'GEN_RUNNING',
 'GEN_SUSPENDED',
 'OrderedDict',
 'Parameter',
 'Signature',
 'TPFLAGS_IS_ABSTRACT',
 'Traceback',
 '_ClassFinder',
 '_FrameInfo',
 '_KEYWORD_ONLY',
 '_NonUserDefinedCallables',
 '_POSITIONAL_ONLY',
 '_POSITIONAL_OR_KEYWORD',
 '_ParameterKind',
 '_Traceback',
 '_VAR_KEYWORD',
 '_VAR_POSITIONAL',
 '__all__',
 '__author__',
 '__builtins__',
 '__cached__',
 '__doc__',
 '__file__',
 '__loader__',
 '__name__',
 '__package__',
 '__spec__',
 '_check_class',
 '_check_instance',
 '_descriptor_get',
 '_empty',
 '_filesbymodname',
 '_findclass',
 '_finddoc',
 '_get_code_position',
 '_get_code_position_from_tb',
 '_get_dunder_dict_of_class',
 '_getmembers',
 '_has_code_flag',
 '_has_coroutine_mark',
 '_is_coroutine_mark',
 '_main',
 '_missing_arguments',
 '_sentinel',
 '_shadowed_dict',
 '_shadowed_dict_from_weakref_mro_tuple',
 '_signature_bound_method',
 '_signature_from_builtin',
 '_signature_from_callable',
 '_signature_from_function',
 '_signature_fromstr',
 '_signature_get_partial',
 '_signature_get_user_defined_method',
 '_signature_is_builtin',
 '_signature_is_functionlike',
 '_signature_strip_non_python_syntax',
 '_static_getmro',
 '_too_many',
 '_void',
 'abc',
 'ast',
 'attrgetter',
 'builtins',
 'classify_class_attrs',
 'cleandoc',
 'collections',
 'currentframe',
 'dis',
 'enum',
 'findsource',
 'formatannotation',
 'formatannotationrelativeto',
 'formatargvalues',
 'functools',
 'get_annotations',
 'getabsfile',
 'getargs',
 'getargvalues',
 'getasyncgenlocals',
 'getasyncgenstate',
 'getattr_static',
 'getblock',
 'getcallargs',
 'getclasstree',
 'getclosurevars',
 'getcomments',
 'getcoroutinelocals',
 'getcoroutinestate',
 'getdoc',
 'getfile',
 'getframeinfo',
 'getfullargspec',
 'getgeneratorlocals',
 'getgeneratorstate',
 'getinnerframes',
 'getlineno',
 'getmembers',
 'getmembers_static',
 'getmodule',
 'getmodulename',
 'getmro',
 'getouterframes',
 'getsource',
 'getsourcefile',
 'getsourcelines',
 'importlib',
 'indentsize',
 'isabstract',
 'isasyncgen',
 'isasyncgenfunction',
 'isawaitable',
 'isbuiltin',
 'isclass',
 'iscode',
 'iscoroutine',
 'iscoroutinefunction',
 'isdatadescriptor',
 'isframe',
 'isfunction',
 'isgenerator',
 'isgeneratorfunction',
 'isgetsetdescriptor',
 'iskeyword',
 'ismemberdescriptor',
 'ismethod',
 'ismethoddescriptor',
 'ismethodwrapper',
 'ismodule',
 'isroutine',
 'istraceback',
 'itertools',
 'linecache',
 'make_weakref',
 'markcoroutinefunction',
 'modulesbyfile',
 'namedtuple',
 'os',
 're',
 'signature',
 'stack',
 'sys',
 'token',
 'tokenize',
 'trace',
 'types',
 'unwrap',
 'walktree']

... Stayed tuned for the next article. We'll still be discussing meta-objects, signals-and-slots, ...

(I know you're not quite anticipating compared to the previous article regarding how you expect the signal-slot system looks like, particularly after seeing these complex and perplexed mechanisms... But, my friend, please believe me that this is the most important feature in Qt in my opinion, and I've devoted time to elucidating it.)

[Qt] V. Widgets: QPushButton and Buttons

Misinahaiya — Sun, 16 Feb 2025 07:05:25 +0000

"Push me, push me, push me hard"

~~Some random Japanese anime~~

Someone who strikes for excellence in a field that he loves

So far, you've gotten something called labels (as in the form of QLabel), and you eagerly want them to obey to your instruction and interact with the user of your tiny, little GUI:

You clicked the mouse (or tapped the track-pad, whatever) like a lunatic; "Quit! - The window, now," you demanded. After a fifteen-second combat, you gave up and said, "Qt's so useless! They can't even make the app gone. Let alone those fancy features. I shouldn't 've trusted a !(random guy on dev.to)[https://dev.to/misinahaiya/series/30375) who'd adulated Qt. Be quick, unfollow him! Uninstall Qt now!" And you unfollowed me and uninstalled Qt.

Okay, let's change the timeline. Back before you want to implement a feature with an action of "Quit", you've read my tutorial (specifically, this one). You know you did not learn how to build a responsive widget to response to the user's desires of quitting the application. You just haven't learned them. So, you would not have complained, or uninstalled Qt. (Hopefully you won't have unfollowed me too, by the way) You - sorry for the long prelude - now finally know that you're looking for a widget called a button.

Different Types of Buttons that You'd Better Know

All types of buttons, except for QCommandLinkButton which is an odd one to flatter Windows as well as Microsoft (will be explained later), inherited the subclass of QWidget: the QAbstractButton class. This class encapsulates the common functions of a button, such as displaying the text, drawing the button borders and the icons (if any), setting whether if they could be toggled (and much more, which will all be explained later).

There are totally 4 classes inheriting the QAbstractButton class, so there are totally 5 types of buttons in Qt. Note that the number of types here indicates the number of types of built-in button in Qt. That is, you could draw your own button and handle the event called signals; I'll guide you when you've learned enough. For now, just stick to the five basic buttons (well, you could understand as so), and it should be rather enough.

Checkbox

A checkbox, represented by the class QCheckBox, is just a type of button with a box allowing you to "check" the mark, which is beside the text of the button:

Actual usage could be found everywhere, for example, in LibreOffice, literally anywhere in every single tab regarding the settings of characters, paragraphs and pages:

Radio Button

A radio button, represented by the class QRadioButton, is a type of button that is often mutually exclusive under the same parent widget, i.e. only one radio button of a group of radio buttons could be checked at once.

Actual usage could be found also everywhere, particularly in Microsoft Paint:

Push Button

This class, as represented by the class QPushButton, is - undeniably - the most well-received class among the four; and it is also a part of today's title. The push button is simple, it is just literally a button:

For actual examples... Well, it's way more prevalent than the radio buttons and check buttons, provided how common are the latter ones. Take the simplest one: a single-buttoned message box written in single-line VBScript (Windows only) has a push button (although it isn't that beautiful):

MsgBox("Hi, there's a push button below")

produces

Tool Button

We'll talk about it later. Basically, this one - named QToolButton - is just like a flattened push button, almost always with an icon instead of some text, and usually with a "Down" arrow:

This class should be the least common class among the four heirs of the QAbstractButton class, yet we'll still be diving into the QToolButton class later.

Command Link Button

For this one though... As it does not inherit the QAbstractButton class, it is really not that applicable and relevant to today's topic. Many methods will be unavailable.

For introduction, this class is just a mimic of the installers for various applications under the Windows Vista or Windows 7 systems:

Thanks for StackOverflow for the image.

Since both Windows Vista and Windows 7 are dead now, we'll just skip it. (For people interested though, do dive into this site.)

Customize the buttons

Now let's discover some useful practices you might opt to use when manipulating the buttons, the views or even the whole user interface design. These class are universally (publicly) available among the heirs of the QAbstractButton class. This series makes the QPushButton as the example as it's too common. Note that there will be significant changes in appearance and internal differences of methods of the same name (e.g. setChecked) between the classes.

Automation

Property autoExclusive is one of the features of the radio buttons, as described above. When a group of buttons (that means they have the same parent widget) is checked, then the others must be de-checked. Normally, we don't need this except for a radio button, whose property of autoExclusive is true by default already.

Property autoRepeat is interesting: normally, if you press a button, the button will recognize the click once only. However, with autoRepeat is set to true, the button recognizes the click signal repeatedly after you've clicked (provided you didn't let go) for autoRepeatDelay millisecond, and the interval is autoRepeatInterval millisecond.

Checkability

If we call something "checked", then it is marked by an indicator that is darker (brighter if you're in dark mode) to show that that thing is active, in progress, or any other synonyms. For example, if I'm using ruler in LibreOffice Writer, there will be a brighter box around the action View -> Rulers -> Ruler:

Similarly, if I opt not to show the formatting marks (i.e. invisible characters, will be covered later in the chapter of QTextOption in relation to QTextEdit), there will be no check marks on the action "Formatting Marks (Ctrl+F10)":

To make the button checkable, use the property checkable. To see if the button is checked or not or to programmatically set the check state, use the property checked. Normally, radio buttons and check boxes are checkable by default (of course!).

While we say a radio button or a check box is checked if the indicator (i.e. check mark for check box, circle for radio button) is present instead of the shadings.

Never call setChecked(true) if checkable() == true. Result or behavior is untested or even undefined.

Text

To display some text or retrieve so, use the property text. Simple and intuitive, right?

Simulation

To simulate the user's actions, there's some method to do so programmatically:

QAbstractButton::click: when called, the button will instantly recognize itself being clicked. Has no effects when it is disabled.
QAbstractButton::animateClick: similar to QAbstractButton::click, but more fancy. It will do some animations to show that the button is clicked. I prefer QAbstractButton::click.
QAbstractButton::toggle: just change the check state of the button, but it will not make the button recognize that it has been clicked.

Example

A small example:

// ... Main Windows
MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
{
    QPushButton *btn = new QPushButton(this);
    btn->setAutoExclusive(false);
    btn->setAutoRepeat(true);
    btn->setAutoRepeatDelay(500);
    btn->setAutoRepeatInterval(300);
    btn->setText("Check me!");
    setCentralWidget(btn);

    // Make the handler of the button,
    // that the function will be called when the button
    // recognizes that it is checked.
    //
    // You'll be introduced in the next chapter.
    connect(btn, &QPushButton::clicked,
            this, &MainWindow::functionToBeCalled);
}

void MainWindow::functionToBeCalled(bool isChecked)
{
    qDebug() << "Clicked!";
    // For your level, just treat this as std::cout.
    // Remember to #include <QDebug>.
}

Result:

Have fun with your buttons along with your labels! Next chapter or two (or presumably, more), I'll talk about the most important and well-received Qt feature - signals and slots. Then, we'll be stepping into the realm of layout management (i.e., in plain English, how to cram the labels and buttons and all sort of widgets into a single widget). Stayed tuned!

[Qt] IV. Widgets: QLabel

Misinahaiya — Wed, 05 Feb 2025 12:50:39 +0000

"Everything is based on information. Information is the God indeed."

Anonymous

You have successfully built your first-ever program using Qt. That's amazing, isn't it?

But after you'd come out of excitement, you soon found out that the user interface is way too ugly.

That's not very good. And that's not very Qt. Qt is not a tool for building ugly applications irrespective of whether the app is usable. In simple English, that's not our goal.

How to make it better? Hopefully, it looks like this:

The label isn't adhered to the margins anymore; instead, it's at the center as a *center widget*. The font weight is bold and mono-spaced to emphasize.

Today, I'll be showing how to beautify the labels.

Widget Basics

This article might be longer than other widget-introducing articles, as I assume you do not know what on earth does the jargon "widget" actually mean, and instead you're just sitting in front of your screen, puzzled, reading my repeatedly use of "widgets," "QWidget, "subclass," etc. in the previous article.

"Subclass" should not be a term that is hard to explain, and I assume you've already known it (sorry for not saying the prerequisite of knowing C++ in the previous articles). Any class inherited a base class is the subclass of the base class.

A "widget," in terms of Qt, is the primary element (the building blocks) for creating GUI. It's the atom of a user interface. Widgets could display data (output), receive user input (input) or as containers of other widgets (process). If you understand how computers work, here are some analogies in the parentheses.

A widget in Qt could also be considered as any object having the base type of QWidget verbatim. The following are all widgets (including the box):

As mentioned in the previous article, QWidget that has a parent is called a "widget", whereas parent symbolizes ownership of a widget, as with QObject.

More introductions of various Qt widgets (up two a hundred ones) are on their ways to this series. Stay tuned!

So How Could I Beautiful My Labels!!?

Why are you always so in haste? Don't worry here it is.

Setting text

Before we move on, let's refresh your memory of setting the text of a QLabel. You could do so by using the method QLabel::setText.

Spaces

Alignment

First, we want it to be aligned. Use the method QLabel::setAlignment to do so. To acquire the current alignment, use QLabel::alignment.

Qt is so powerful that it supports the alignment such as:

Qt::AlignmentFlag::AlignLeft:

Qt::AlignmentFlag::AlignRight:

Qt::AlignmentFlag::AlignHCenter:

Qt::AlignmentFlag::AlignJustify:

You could also adjust the vertical alignment by using the | operator. For example,

Qt::AlignmentFlag::AlignRight | Qt::AlignmentFlag::AlignTop aligns at the top-right corner:

Similarly, Qt::AlignmentFlag::AlignLeft | Qt::AlignmentFlag::AlignBottom aligns at the bottom-left corner:

Whereas Qt::AlignmentFlag::AlignVCenter aligns as the name suggests:

There's a special enumerator: Qt::AlignmentFlag::AlignBaseline. It ensures that the alignment is in accordance with the text baseline in many labels lay outed horizontally instead of the text:

Note that you could use Qt::AlignmentFlag::AlignCenter as Qt::AlignmentFlag::AlignVCenter | Qt::AlignmentFlag::AlignHCenter. They carry the same meaning.

What if I don't want to do alignments?

Indentation

Then, you have indentation. Use QLabel::setIndent to set, and QLabel::indent to acquire the current value.

Note: as you have observed, there are usually two methods: the acquisition method of a specific property of its own name, and the setting method of it using the format of set plus the capitalized name of the property. For example, for alignment, we have setAlignment and alignment. For indent, there are setIndent and indent.

When there's exception, I will tell you. From now on, I call them "properties" and you know the getters and setters, as every character counts in this series.

If alignment is Qt::AlignmentFlag::AlignLeft (the default), then the indentation will be on the left edge, and if alignment is Qt::AlignmentFlag::AlignTop, the indentation will be on the top edge and so on and so forth.

Setting alignment for centers do not have any effect.

If both Qt::AlignmentFlag::AlignTop and Qt::AlignmentFlag::AlignLeft or etc. are set, then both vertical and horizontal alignments will be indented:

Margins

You could also set the margins using the property margin.

Margins add more space around the label, irrespective of whether the label is indented or aligned or not. The default margin is 0 pixel (it is also counted in pixels).

Precisely, the margin is the distance between the innermost pixel of the label('s border) and the outermost pixel of contents (of the label).

Wrap

Wait... So, you've just tried out the "justify" example with indentations and margins and all sort of fancy things, but you got this whole long thorn instead of a smaller, (cuter?), fitter version:

You're then looking for the property wordWrap. By using QLabel::setWordWrap(true), you could make the text be wrapped and it should look like this:

Normally, it wrapped according to the size of the window, or the parent widget.

Using HTML

QLabel supports a limited subset of HTML, as well as other editor-like widgets we will cover later. You could just pass in valid and simple HTML code in order to do rich-text formatting.

You could beautiful your text in terms of that.

// I assume you've created your project
// ...
{
    QLabel *label = new QLabel(this);
    setCentralWidget(label);
    label->setAlignment(Qt::AlignmentFlag::AlignCenter);
    label->setMargin(5);
    // label->setIndent(10);
    label->setText("<p style='font-size: 25px;'><b>Beautified</b></p>");
    label->setWordWrap(true);
}
// ...

You could disable it by using the property textFormat. There are four Qt::TextFormat enumerators defined:

Qt::TextFormat::PlainText makes the label displaying plain text:

Qt::TextFormat::RichText makes the valid HTML code get parsed and interpreted, as shown as the above example. Also, if you pass in the argument Qt::TextFormat::AutoText, it determines whether if the text is rich text or not by matching the HTML tags. (See function mightBeRichTextImpl in Qt sources). If it is rich text, then Qt::TextFormat::AutoText becomes Qt::TextFormat::RichText. Otherwise, it becomes Qt::TextFormat::PlainText.

You could also add markdown text via Qt::TextFormat::Markdown from version 5.14 on (the latest one is 6.8).

Editable Text

Those are not funny and interesting enough!

Allow me to introduce the final boss: a QLabel could be a simple text editor.

Using the property textInteractionFlags, you could set that:

Qt::TextInteractionFlag::NoTextInteraction:

<a href='https://google.com'>Google</a>

The link seems to be not able to process the hover (mouse-on) events and seems to be disabled, and you could not access so.

To make it accessible, use Qt::TextInteractionFlag::LinksAccessibleByMouse:

Though it still looks like disabled, you could hover it and see the hyper-link cursor!

To make the keyboard could also access the link via the tab key (called focus, which will be introduced to you later), take the Qt::TextInteractionFlag::LinksAccessibleByKeyboard in bitwise-or operation (|) with LinkAccessibleByMouse:

    label->setTextInteractionFlags(Qt::TextInteractionFlag::LinksAccessibleByKeyboard | Qt::TextInteractionFlag::LinksAccessibleByMouse);

If you wish your link is readily available and open in the default browser immediately after activating it (pressing it or clicking Enter, use the property openExternalLinks and set it to true.

It's the same for selection: TextSelectableByMouse by dragging and TextSelectableByKeyboard by using the Shift key(s) and the arrow keys:

<p style='font-weight: 700;'>Lorem ipsum dolor sit amet.<br><a href='https://google.com'>Google</a>

    label->setTextInteractionFlags(Qt::TextInteractionFlag::TextSelectableByMouse | Qt::TextInteractionFlag::TextSelectableByKeyboard | Qt::TextInteractionFlag::LinksAccessibleByKeyboard | Qt::TextInteractionFlag::LinksAccessibleByMouse);

To investigate whether there is text selected, use the method hasSelectedText. To see the selected text, use the method selectedText.

Finally, the final boss of the final bosses: Qt::TextInteractionFlag::TextEditable. By using this on QLabel, your label could be a mini-text editor:

    label->setTextInteractionFlags(Qt::TextInteractionFlag::TextEditable | Qt::TextInteractionFlag::TextSelectableByMouse | Qt::TextInteractionFlag::TextSelectableByKeyboard | Qt::TextInteractionFlag::LinksAccessibleByKeyboard | Qt::TextInteractionFlag::LinksAccessibleByMouse);

Now, you know how to beautify your tiny text label!

[Qt] III. Hello, World!

Misinahaiya — Tue, 04 Feb 2025 12:25:14 +0000

"Hello, World!"

First B Language Program, The B Language Tutorial, Bell Labs

So you have been forced to sit in front of your computer, looking at the screen for one hour or two, to install the behemoth Qt. Then, you really wanted to try out the best IDE in the universe - Qt Creator, but you were intimidated by the (slightly?) overly posh user interface:

You did not know what to do.

That's normal, as it is the first time that you got to know Qt. Let me introduce how to create your first Qt application.

"Hello, World!" is probably the most iconic and the most well-known programming language example for absolute beginners. So, for Qt, even it is just a comprehensive tool, I will still be introducing you "Hello, World!" as the first example ever for our series.

Projects (Oh My!)

Every app, created or edited on Qt Creator, is called a "project". Don't be misguided by the name, a project need not to be very complex or large.

To create a project, you should select the "File" menu on the top-left corner. Select "Project" to create a new project.

Then, a dialog called "wizard" will appear. It guides you to create your first project:

Here, just choose "Application (Qt)", which implies using the C++ programming language. We are not going to use Python or develop web applications in Qt throughout this series, are we? So, leave those fields intact. Click "Choose".

After that, you would see the dialog below:

Name your project a reasonable and clear name. I'll use "Hello World" for this article. Do note that special characters (including spaces ' ' yet not hyphens '-' nor underlines '_') are illegal characters in project names, i.e. you cannot use them in naming your project.

Normally, you do not need to create any folder for your project, as Qt Creator will create it for you. As for me, I prefer put my projects into a directory called "Projects" under the location of the Documents folder. But trust me, changing this will not affect anything. It's just a matter of preference.

If you decide to use this directory continuously and throughout this series (and presumably also continuously for your own app development), remember to check the check box "Use as default project location." It will make Qt Creator recognize your preference.

Click "Next," if there are no problems. Then you'll see a simple yet standard combo-box:

I'm generally against you using qbs, as it's outdated and not maintained for more than 5 years.

You could choose QMake, the own Qt build system for C++. But in this tutorial, I'm going to use CMake, as it is supported by the Qt 6 (the latest version) more than that of Qt 5. In other words, QMake will still be, inevitably, deprecated in the future.

If you really love QMake, there are a lot of useful and official guides online that you could make a reference of. If you do pure Qt, there are no difference between QMake and CMake except the syntax. They both generate Makefiles. But due to the official support and the latter one is more compatible to external tools (e.g. OpenCV uses CMake), I do CMake.

Anyway, let's do away with the page and flick the dialog to the new page:

Now, de-check the "Generate From" check box.

What does that action do? Well, it launches the so-called convenient tool of "Qt Designer", which is already bundled in and bound with Qt Creator. You could just actually craft a good-looking, fancy user interface without any coding involved.

Sounds nice, right? We'll abstain from using this throughout the whole series. Why?

Think about it: athletes are trained with heavy and weary things called "burden" on their backs, and when they do really be in a race, they'll be like running above the sky. Same thing for your Qt odyssey: if you do want to have absolutely no dark corners on how you could craft the user interface and on how to be an architect at user interface, don't use it.

Instead, with my detailed explanations, you'll be very good at building everything from scratch under the Qt framework. After that, you could then try out the Qt Designer.

Je suis en train de essayer le Qt Creator!

Ok, we'll not be doing French or other things here, at least for now. Internationalization and translations will be introduced and be there later. Skip them now to be simple. (Well, Qt has a astonishingly meticulous internationalization system. I can't omit the elephant in the room, but to explain it thoroughly you must have a solid foundation on the topics we'll be covering later.)

Okay, kits! Well, for kits, my advice is, select the default one. If you just installed one version of Qt (e.g. Qt 6.8.2), on Windows, "MinGW" will then be shown and be the default. On macOS, it should be "clang" or "LLVM". On GNU/Linux and (mostly) the others, it should be "GCC".

If not, I suggest you de-checking the default ones and checking these. The tutorial will be focusing on these compilers respectively; unless you have a solid foundation on those kits, or any other reason that you have to use those kits.

(Note that on Windows, when we reach the point of creating web browsers, "MSVC" must be used instead of "MinGW". I'll explain it why later. Now, just choose "MinGW". In most of the time, it will do)

Well... Here, we aren't going to do Git. If you wish and you have git, you could craft your own repository as well. But that's not for me, due to simplicity.

Click "Finish". Yippee, we're done!

Note that you could always change almost all the above configurations in the "Project" column on the leftmost bar of the Qt Creator.

Building the Real "Hello, World!"

Let's look at the three source files created:

main.cpp:

#include "mainwindow.h"

#include <QApplication>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    MainWindow w;
    w.show();
    return a.exec();
}

mainwindow.h:

#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <QMainWindow>

class MainWindow : public QMainWindow
{
    Q_OBJECT

public:
    MainWindow(QWidget *parent = nullptr);
    ~MainWindow();
};
#endif // MAINWINDOW_H

mainwindow.cpp:

#include "mainwindow.h"

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
{
}

MainWindow::~MainWindow()
{
}

Where MainWindow is a subclass of QMainWindow (as suggested by its name), and the latter one is a subclass of QWidget.

Understanding the files

In the main file, the QApplication object is imported and used before the creation of the MainWindow type. That's correct, as there must always be an, and only one, QApplication instance before the creation of any paint-devices. In simple words, any QWidget must be created after the creation of a QApplication.

This is because that QApplication is considered as a coordinator of the different widgets and objects: how should they interact with the user and the system? How should they be arranged? How should handle their lives (e.g. construction and destruction)? A QApplication object is always responsible for these.

By just looking at its methods: setDoubleClickInterval, setCursorFlashTime, setStartDragDistance, setStartDragTime or topLevelWidgets could prove so.

Note that the application object needs to have the arguments as the parameters.

After that, at the MainWindow constructor, you could see a parameter called parent. By practice, if a QWidget does not have a parent, it is the top-level widget (i.e., a window).

If it does have, then we say the ownership of the widget is transferred to its parent widget. It means that the widget becomes the child of its parent, and when the parent got destructed, all of its children also got destructed, even if you had not implemented the destructor method to demand explicitly the program and Qt to destruct the children, for it is applicable for every QObject and its subclasses.

Calling the show method shows the main window (also for any other QWidget). If it is already embedded in another QWidget (and generally it becomes a child), calling this has no use.

Finally, the app should return the value of exec. The method exec indicates it's time for the application to receive user input, so-called "entering the main-loop". It generally returns 0, indicating that no error occurred.

Now, key the shortcut Ctrl and R, or click the menu as follows: Build -> Run. You could see an empty window if your compiler is okay:

Where's my Hello World?

Don't be in haste. If you saw an empty window, that indicates you have a good compiler and you're going to do so.

Change the mainwindow.cpp as follows:

#include "mainwindow.h"

#include <QLabel>

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
{
    QLabel *label = new QLabel(this);
    label->setText("Hello, World!");
    setCentralWidget(label);
}

MainWindow::~MainWindow()
{
}

Tips: Every QObject needs to be in pointer form if they need to interact with other objects. In the above example, label is set as the central widget by another QObject, MainWindow.

We included the QLabel widget. It's another subclass of QWidget that used to display read-only text. If you have any experience in designing GUI, you might have come across similar widgets. For example, in TCL/Tk, you may have Label. In Wx Frameworks, you have wxStaticText. They all mean the approximately same thing.

To set the text, you could just pass the text as strings to the method setText. After that, to make it the central widget (i.e., widget that occupies most of the space of the main window), use the method defined in QMainWindow: setCentralWidget.

Now, build again.

Succeed!

Hello, World!
Hello, Qt!
Hello, Everyone!

[Qt] II. How To Install Qt

Misinahaiya — Wed, 29 Jan 2025 14:16:46 +0000

"Well begun is half done."

Aristotle

An adviser or an instructor? Or for naysayers, an agitator? Ha ha, that's what you would call me for I have (hopefully and probably) persuaded you to learn Qt with me in this series.

Without being a Victorian writer with much abstruse metaphors and without further ado, let us (really) start this series now.

What will we be doing today?

Let me prompt you a question first: what would you do before using a piece of software, given that "software" could also be a tool or a library used in different programming languages.

Don't answer me that you're going to download the package from the Internet or going to learn how to use the piece of software. Those are not quite accurate. Now, as a rule, before we use a piece of software (except the ones which are out-of-the-box zip files or install-on-disks programs), we must install it using an installer, as you would do for 90% of (especially Windows) programs.

Qt can't be an exception. It must find its way to install itself.

It All Started at that Snowy Night, on that Website...

Qt-dot-I-O

Open your little browser and type in this address: qt.io. This should be launching the official website of Qt. Any docs or examples that you would like to take a look later may also be found here. Here is the screenshot from about February, 2025. Your version may vary:

Click on the button "Accept All Cookies," as what you'll do when visiting every website. Normally, accepting all cookies does no harms to your computer as it only stores your footprint or preferences for a short period of time but not any personal data, so that the web server could remember your choice and be improved. If you really mind these configurations, do configure them in "Cookie Settings."

Anyway, after this, click on the "Download. Try." button, or the button somewhat similar. You'll see (again, your version may vary):

Click on the "Community User" link. As mentioned in the previous article, Qt is dual-licensed. If you do use Qt in your business or use it as a tool to generate profit, you need to pay the Qt Group. Otherwise, as long as you're open-sourced (or otherwise complying with the LGPL License), you're free to download to use, and good to go to install.

Then, scroll till you see a banner called "Looking for Qt Binaries?". Your version may vary, but there should always be a banner somewhat similar to this, and you will click on the "Qt Online Installer".

Choose the operating system you're using. Be careful of the architecture, i.e. whether you're using a 32-bit computer or a 64-bit one, or you're using an Intel chip or an ARM chip (i.e. Apple chips series) or not. If you do not, Qt would be very naughty.

I'm using a 64-bit Windows with an Intel chip. But the procedures should all be the same.

If there are no Internet problems, you should download your online installer in a short time.

Running the installer

Execute the installer. You'll be prompted to fill in your Qt-account and password. Believe me, it's very safe to register one. You won't be giving any crucial personal information to the Qt Group, but instead, just a few steps would do and you could access to the Qt Forum (the programmers' forum similar to Stack Overflow) and the Qt Academy (the place where you could learn Qt better if you found these articles unhelpful), besides the rightful access to the installer. It's quick and completely free without any credit cards. Believe me.

Then, click "Next." You will agree to the License Agreements, which is all based on the famous open-source license, the LGPL License, as mentioned previously.

Preferences

Click "Next" twice. Select if you would like to contribute to the development of the Qt's exclusive IDE, the Qt Creator. It's always Okay not to opt to improve, and no features provided would be affected. But as an open-source writer and developer, I always choose "Yes," and believe me, there's not really much information that the Qt Group could steal. Click "Next" again.

Selecting paths and modes

Now, it's time to select the installation path. Normally, I suggest you choosing C:\Qt on Windows, or ~/Qt on UNIX-based systems (macOS, GNU/Linux, BSDs, etc.), for as a generally rule of software development, choosing the given and default installation path should always be the easiest to manage or to update.

Also, choose "Custom Installation." I'll guide you how to choose the components next.

If you have already a favorite code editor or IDE for your .cpp files or .h files, etc. like CLion or Kate, then I suggest you de-checking the option "Associate common file types with Qt Creator." It'll override your settings and make your favorite editors not be the default ones to edit C++ source files. On the other hand, if you are just a newbie at C++, I strongly suggest you checking this option. Qt Creator is one of the most powerful and strongest free-and-open-source IDE on this planet for the C++ programming language.

Choosing components

Now it's the big part: how to choose the components? Let me dissect for you:

For Qt Design Studio, it's a powerful tool to design for QML file (the programming language crafted by Qt), even more powerful than its exclusive C++ IDE, Qt Creator. QML is basically the spokesperson of the mobile support of Qt, as well as Nokia (Nokia has once owned Qt from 2008 to 2012). But since I'm not that into Qt-based mobile development than native APIs or web-based APIs, I will not introduce it as much as I will do for Qt Creator later this series. Also, without QML, Qt Design Studio is not really that used for C++-based Qt Widgets, where the Qt Group started with.

Long paragraph short: choose it if you're really a copain of Qt-based mobile development. I am not.

For extensions, they are the extended components for the advanced Qt users to develop their application with demand of more advanced features. They include:

Qt Insight Tracker provides the programs tracking application usages of their application or device. I have never used it and thus it will not appear in this series.
Qt PDF provides the programs rendering PDF documents, including showing, bookmarking, parsing and interpreting them. I will be using this component later this series, as to make our own PDF viewer.
Qt Web Engine provides the programs rendering web page and displaying them, based on the Chromium cores. In other words, you could just build a full-featured browser using this component. (How powerful Qt is.) We'll, definitely, be using it later this series for making our own browser.

Here's the detailed explanations on the cores of the Qt components. You are advised to select all of them. To select all of them, just check the version number:

I'm just trying as I might to sum up the key Qt components sentence-pass and in simple words.

Active Qt: a C++/Qt binding of the ActiveX framework on Windows.
Qt 3D: the best 3D rendering tool by native Qt, with features like Unity or Unreal Engine.
Qt 5 Compatibility Module: some useful features like QTextCodec are marked deprecated and removed in Qt 6 by the airhead Qt developers; and they're requested to add them back. (But this module will still be replaced in Qt 7, so sad).
Qt Charts: a module for plotting 2D charts.
Qt Connectivity: a module for basic Dial-up, (W)LAN, USB and VPN support.
Qt Data Visualization: a module for plotting 3D charts. (I don't know why they did not name it "Qt 3D Charts".)
Qt Graphs: a module aims for integrating and replacing Qt Charts and Qt Data Visualization.
Qt HTTP Server: a module for serving files by the HTTP protocol, as the name suggests.
Qt Image Formats: a module for providing extensions to interpret and parse different image file formats, namely.gif, .icns, .ico, .jpeg, .pdf, .svg, .tga, .tiff, .wbmp and .webp on Windows 11.
Qt Language Server: a module for providing support to the Language Server Protocol by Microsoft; it's mainly for the C++ and QML programming languages.
Qt Location: a module for accessing and presenting map data, making touch gestures, querying for a specific geographical location and route and adding and searching places and layers on top; in other words, a module like Google Maps.
Qt Lottie Animation: a module for using the Lottie animation framework in QML.
Qt Multimedia: a module for recording and presenting the multimedia data platform-independently, including videos, audios and cameras.
Qt Network Authorization: a module for providing network authorization, namely Open-Authorization versions 1 and 2.
Qt Positioning: a module for testing and retrieving position information like the current location and speed.
Qt Protobuf and Qt GRPC: a module for parsing specific data formats like Protobuf (Protocal Buffer).
Qt Quick *: a module for assisting QML libraries.
Qt Remote Objects: a module for manipulating the remote devices like GPS and printer access.
Qt Sensors: a module for sensing the device environment, e.g. speed, acceleration, humidity, axes, etc.
Qt Serial Bus: a module for accessing various serial bus protocols, like CAN, ModBus, and etc.
Qt Serial Port: a module for accessing various serial port functions like configuration, I/O operation, etc.
Qt Shader Tools: a Qt port for the Shader Tools.
Qt Speech: a module for converting text to speech. The voice is similar to the Google Translate ones.
Qt State Machines: a module for creating state machines.
Qt Virtual Keyboard: a module for creating virtual keyboards. (That are, the ones you will see on phones.)
Qt Web Channel: a module for enabling peer-to-peer communication between a server (could be made with QML or C++) and a client (could be made with front-end languages like HTML or JavaScript, or QML).
Qt Web Sockets: a module for providing web-based protocol designed to enable a two-way interactive communication session between a client app and a remote host.
Qt Web View: a module for making browsers, same as the Qt Web Engine above, but it is for the QML fans.

Also, you will select the following build tools of their latest versions:

MinGW,
CMake,
Ninja and
OpenSSL Toolkit.

They're useful in building in different scenarios.

Lastly, the first-in-cosmos IDE, Qt Creator, should also be installed of its newest version. If you have space, I do suggest you also installing the debugging symbols and plugin developments.

The trivia

Finally, click "Next" to agree with (again) the GPL/ LGPL license. Click next

(Windows exclusive): On windows, there's an additional step: you're then about to choose the start menu folder. If you wish to access Qt Creator (and, presumably, the other essential tools) from the start menu, add Qt to the menu, then click "Next." Don't hesitate:

Then, you're guided to a page called "Ready to Install." You will know how much space will the installation cost. Normally, these configurations cost around 40 GB, which is still quite feasible on modern PCs. However, if you feel they're still too big, try de-select some components like the additional libraries or external tools by clicking the "Back" button multiple times.

Click "Install".

Finishing

As I have already had Qt installed, I could not really show you the whole installation process (with apologies!). The installation takes about one hour or two, depending on your Internet connection and the query/ request of the Qt code mirror that day.

If you finished your installation, you can relaxedly check out the newest README file, explore Qt Creator, and most importantly, prepare for your odyssey of Qt.

[Qt] I. Why you should learn Qt

Misinahaiya — Tue, 28 Jan 2025 10:21:11 +0000

"The future is written with Qt."

Qt Group

There is a general rule of software design, irrespective of where you are; regardless of the type of software you are crafting: I generally do not consider any frameworks or libraries will survive under the overly keen competitions among different tools in assisting the overall application design, nor any additional libraries that are not endorsed by the tech giants or the standards.

Yet, Qt is obviously the exception - the extraordinary exception that will not perish in time. Ever.

Released back in 1995, Qt continuously showed its unparalleled talents in producing either small-scale toy applications, as well as the heavy and strong titans. From time to time, software of various types and functions may disappear from the shelves, and be forgotten by the end users who soon have found better alternatives. When, in the next time, you surf the Internet or especially the Application Store, do remember peek that whether the things you installed on your computer a decade ago is still here. I could guarantee that over 75% will be gone without leaving a word nor reason.

Undoubtedly, the ever-increasing demand from the market and the overly keen competition contribute significant reasons for software, tools and all sort of things being gone, which - the latter ones - were once all the rage. But, what's more, there are some reasons also contribute as significantly as the external factors:

What Are the Advantages of Qt?

So, what reasons brought the perished apps or packages down? Or, in other words, what made Qt flourish? Let us investigate.

First, it's cross-platform

Yep, you're right. Stepping into the mobile era could we hardly recognize that how hard it is for cross-platform compatibility. In the bygone, dark days of computers of the 1980's to 1990's, where a single operation of "one-plus-one" took years and a laptop looked like a printer, every single piece of code was basically invalid on another machine, even it could be compiled successfully on one.

As of then, computer scientists struggled. Why? It is just simply because that they could not find a stable solution of stable building and stably deploy the stable code. They were seeking their utopia of "Write Once, Build Everywhere".

"Will these come true?" Unfortunately no, at least in the 80's, as in the mid-1980's making an cross-platform solution was far-fetched as there were not any standardized descriptions of how computers execute code via their chips and CPU's. For example, assume that an Intel CPU port 0xE which served for Microsoft DOS or Windows might be responsible for jumping, but an ARM chip will just be on strike.

But things have to go on. A cross-platform solution must be presented. Then, many firms had decided to make some protocols and all sort of fancy things to make cross-platform possible for the major programming languages like C/C++, Java or Python. As intended, the pursuit of cross-platform software successfully filtered a considerable portion of old and unstable pieces of software.

So, why are the protocols and the cross-platform compatibility related to Qt? Well, as you might have already guessed, Qt is an extremely powerful library in terms of cross-platform compatibility. Basically, without any modification could your code be compiled on every platform as long as Qt itself supports so, given that you have not used any external or 3rd-party libraries.

This already filtered out the some potential alternatives like Windows UI or Cocoa. Might you ask, what about Python's Tkinter or C++'s WxWidgets? Aren't they also cross-platform solutions?

Second, it's feature-rich

To measure how mature (or good, whatever) a library is, the metrics we should be using is not quite the cost (let alone being open-source or the license used under), nor the community engagement. These are not that important as the metric: features. How many classes or namespaces of different genres the library has? How many languages does it support (or, how is the internationalization going)? How, or if it is, possible to implement both simple apps like a Notepad or complex apps like GIMP?

It is, undoubtedly, filtered out another good portion of the potential alternatives of developing applications.

I have used almost all the major application development frameworks, including Python's Tkinter (and some of its derivatives), C++'s Qt and WxWidgets, as well as Java's Swing. All of them are not that holistic enough. How? Why?

A picture is worth a thousand words. Look at the Qt classes:

These are not the screens of the crackers used in films. These are the synopsis of all the Qt classes. Not only GUI design, but Qt is able and mighty to deal with networking (Qt Network), code editing (Scintilla), communicating with D-Bus (Qt D-Bus) on Embedded or ActiveX servers on Windows (Qt ActiveX), unit testing (Qt Test), doing Bluetooth (Qt Bluetooth), charting (Qt Chart and Qt Data Visualization) and XML (Qt XML), authorizing using Open-authorization (Qt OAuth), doing with SQL (Qt SQL) or serial ports (Qt Serial Port), and making web applications or browsers (Qt Web Channel, Qt Web Socket, Qt Web Engine and Qt Web Engine Widgets). Want to play music or video? Even better, record one? Use Qt Multimedia with Qt Multimedia Widget! Want to make your own 3D Google Map or Google Earth with JavaScript? Use the Qt Quick (3D) of the Qt QML (Qt's own programming language) with Qt Location! The list goes on and cannot reach an end.

How to prove so? Look at the big players in software design:

Adobe's Photoshop Element uses Qt.
Google's Google Earth uses Qt.
TeamViewer uses Qt.
Telegram uses Qt.
VideoLAN's VLC Player uses Qt.
Oracle's Virtual Box uses Qt.
Dreamworks Pictures uses Qt.
Disney's animations use Qt.
Chinese office, the WPS Office, uses Qt.

Again, the list goes on and cannot reach an end.

"Okay, I admit that Qt is powerful. But this does not prove the other cross-platform frameworks and persuades me to learn Qt." Yep, how about WxWidgets or Swing, which was once favored, or Tkinter? Well, they are, in the contrary, not that feature rich. An example: you cannot paint widgets freely in WxWidgets or Swing as it does not provide any good interfaces for the program to customize the widgets and regions (ah yes, customization should be an important feature). In Tkinter it's crazier and more nonsense: it does not even provide any ways for the program to paint their widgets.

A more subtle example: you have all encountered the "Justify" option in Microsoft Word or LibreOffice Writer, right? So you could expect that every GUI library has an option on its rich-text editor: justify. Disappointingly, neither WxWidgets nor Swing nor Tkinter implement so. Only Qt, which is almost almighty in every aspect of application development could do so. Furthermore, you could launch an HTML file in rich editing (yep, besides normal web browsing) with a bit limited support. Frankly, I haven't encounter any frameworks with this level of meticulous design.

You Couldn't Say Qt Is Flawless

I do admit that Qt is not flawless, as any other thing in the word does.

It's devilishly hard!

Qt does, indeed, have a steep learning curve. You should get to know the basics before you get on to craft any projects - this rules is applied everywhere, for every tools it is the general rule. However, in Qt, the "basics" should be defined as the "advanced pattern" in other tools. Setting up a project might include necessary knowledge on CMake or QMake (either one used for the build system), QObject and QApplication, as well as the model/ view structure and the basic uses of each widget.

But fear not! For in this series I am going to help all of you. From as simple as the basic moves like creating a QApplication instance, to the most advanced moves like crafting a LibreOffice Writer-like application as the hands-on projects, I am going to explain every detail that matters as I might. The key is, to have a committed heart in learning Qt and to try to do everything as you might, and enjoy your learning process. That was also my key believes in learning Qt.

I don't have a buck!

Regarding to the cost, Qt (and almost all of its derivatives) has a dual-license system. To explain, if you sell your application (or make any profit from your application) developed by Qt, you have to pay Qt an amount of money calculated from the profit you have gained. Someone groaned that the system is expensive and unfair, as they have only seen the expensive Enterprise solutions. Indeed, they are expensive. They just mainly provide supports for the non-developers in the company for those which have already written on the documentation. So, we, as developers, do not really need these kinds of services like instructive or installations.

They did not also consider that if you did not earn any profit from your applications, you do not need to pay Qt as it uses the LGPL license, which enables you to use the software freely under certain conditions. Qt is fair, if you do not let others pay a buck, you do not need to pay a buck.

In A Nutshell...

All these point to that broad and open road, where both firms like Google and Oracle, and individuals meet and are more crowded than the Times Square in New York. The road is called, "Go Learn Qt".

This editor is built entirely with Qt and C++. Do you want to have one? Stay tuned to this series and wait till the end, where I will teach you how to build an editor like this, an editor like Microsoft Word and many more.

DEV Community: Misinahaiya

[Qt] VIII. Smart Memory Managements

QPointer

Practicality and usages

QSharedPointer

Practicality and usages

QWeakPointer

Practicality and usages

QScopedPointer

Practicality and usage

QObject

Practicality and usage

[Qt] VII. Multi-threads Signals and Slots

Prerequisites

Connection Types

Little Example

Results

Explanations

Conclusion

[Qt] VI. Signals-slots and Meta-objects

The Heart's Heart of Heart

Flowers

Full code

Why?

Meta-object Compiler is a True Magician

What does the QMetaObject::activate do?

Connecting

How do I know the indices, in order to call the activate(), metaCall() or qt_metacall() methods?

QMetaObject

[Qt] V. Widgets: QPushButton and Buttons

Different Types of Buttons that You'd Better Know

Checkbox

Radio Button

Push Button

Tool Button

Command Link Button

Customize the buttons

Automation

Checkability

Text

Simulation

Example

[Qt] IV. Widgets: QLabel

Widget Basics

So How Could I Beautiful My Labels!!?

Setting text

Spaces

Alignment

Indentation

Margins

Wrap

Using HTML

Editable Text

[Qt] III. Hello, World!

Projects (Oh My!)

Building the Real "Hello, World!"

Understanding the files

Where's my Hello World?

[Qt] II. How To Install Qt

What will we be doing today?

It All Started at that Snowy Night, on that Website...

Qt-dot-I-O

Running the installer

Preferences

Selecting paths and modes

Choosing components

The trivia

Finishing

[Qt] I. Why you should learn Qt

What Are the Advantages of Qt?

First, it's cross-platform

Second, it's feature-rich

You Couldn't Say Qt Is Flawless

It's devilishly hard!

I don't have a buck!

In A Nutshell...

`QPointer`

`QSharedPointer`

`QWeakPointer`

`QScopedPointer`

`QObject`

What does the `QMetaObject::activate` do?

How do I know the indices, in order to call the `activate()`, `metaCall()` or `qt_metacall()` methods?

`QMetaObject`