QT Signals Slots

Signals and slots are like direct links. It's an event system where a signal will pass its arguments to the connected slot. It's similar to python and probably the most peculiar feature of QT.

The Signal slots paradigm makes GUI desing a lot simpler. Something happens->do something else. They are also thread safe for good measure.

Internally QT will translate signals slots and connect in real C++ code in meta C++ files before the real compilation begins.

Here I added a slot to the main class. It's a public method with a macro definition used by QT for his translation into real C++ code.

class MainWindow : public QMainWindow
{
    Q_OBJECT

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

    public Q_SLOTS:
        void txt_update( int num );

    private:
        Ui::MainWindow *ui;
};

The slots take care of writing an integer inside a line control


void MainWindow::txt_update( int num )
{
    User::Qt_utils::qline_show_int( ui ->txt, num );
}




I have an object with a signal. The signal too is public and declared as macro.



class Sender : public QObject
{
    Q_OBJECT

    public:
        Sender();

    Q_SIGNALS:
        void send( int num );
};





Here is the code inside the constructor of the main window.

I create the sender object.

I call directly the slot to update the control and initialize it.

I connect the sender output with the slot input.

I call the sender object which will pass it's argument to the slot automagically!

//I can call a slot directly
    //This slot is set to update the txt control wint an integer when called
    this -> txt_update( 0 );

    //QT will actually add more c++ files to handle signals and slots in real C++ code
    //Connect the signal coming from the sender class to the slot of the Main Window class
    //singal and slot must have same arguments in this style of connect
    connect
    (
        &my_tx,                     //Reference to source signal object
        &Sender::send,              //Reference to the source signal method. It's just the definition and it's not tied to the individual object.
        this,                       //Reference to the dest slot object. In this case I use the current class instance
        &MainWindow::txt_update     //Reference to the dest slot method. It's just the definition and it's not tied to the individual object.
    );

    //I can send a signal by simply calling the method directly
    //This will cause the slot of the main class to be activated with the same argument of the sender signal
    my_tx.send( 17 );

QT Add a new Kit

Create a new compiler with the binaries

This is the easy part.

ABI is not functional, is just used to sign the compiler and for QT to detect inconsistencies.

Here is where things get hard

QMAKE create a makefile. It uses .pro and a configuration file stored in the mkspec folder of the QT kit to configure everything. You need QMAKE.CONF and QPLATFORMDEFS.H configured properly for everything to works and for the makefile to be done the right way.

QT needs to be built USING the kit compiler in order to generate all the QT dll.

Those .dll are required for the binary to work and have to be bundled with the application.

STATIC:

Creating a static application with QT is a nightmare. In order to do it you need static libs, not dinamic link libraries, and to do so you need to recompile QT the right way with the right compiler to generate them.

After that you need to configure the kit to make a static compilation.

TOOLCHAIN

“Shadow built” is used to output in a folder different from the source project

“qmake” is the command line that is effectively being executed to create the makefile

“make” is used to call the compiler with all dependencies and generate the binaries

“Build environment” is used to add the paths required to build, like the compiler include and lib folders, the compiler binaries, etc...

The hardest thing to do is to configure QMAKE to generate the makefile the right way with all dependencies.

KITS

This is the final thing that ties all together

“File System Name” is useless

“Sysroot” is used to specify the system libraries. Works without but results in the binary duplicating some dependency/library.

“Compiler” is the one specified in the compiler slide

“QT Version” specifies the binaries and QT dll to use. If you target arm you need the QT dll compiled for arm to bundle with the binary for it to work

Qt mkspec is where the configuration file used by qmake to generate the makefile lay

DEPLOY

To deploy an application so that it can be executed without the QT toolchain you need to bundle in all the .dll dependencies.

The easiest way to do so is to execute and bring in the .dll that causes trouble.

Take care to bundle the right .dll. One compiled for another architecture, or with the right architecture but the wrong compiler won't work. You can find the .dll of QT here:

Each kit in the /bin folder has all the .dll compiled with the kit. You need to bundle them with the executable of your project or setup a system variable to tell where to find them.