The ubiquity of memory leaks in GUI applications.

When I was studying C++ as an Independent Student, we were taught that, as a good programming practice, we should always delete any objects which we had created with the ‘new’ allocator, including, to do so in the destructor of any objects, which created those members in their constructor. Just to define a little bit, what this means, I need to state some facts:

  1. In C++, we can declare objects to exist as such, without using ‘new’, and without initializing object pointers to point to them. When we do so, they are allocated on the stack, their constructors are called in turn, and, when our function call returns, the compiler makes sure that the stack is cleared, at which point the compiler also makes sure that the destructor of such objects is called automatically. In much programming, including GUIs that we build with Qt5, this is considered to be the less-favoured way to do it by default…
  2. As an alternative, we can declare a pointer to a class object to exist. This pointer could reside on the stack, or, it could be a member of the class, and thus, be a property of each object. Regardless of where this pointer has been put, we call ‘new’ to create a new object, and the address returned by ‘new’ is stored in the pointer, by our own explicit code, either in the constructor if the pointer is a class member, or elsewhere if the pointer has been created in the middle of a function-call.
  3. The pointer, a member of the class, might just receive an address from someplace else, thus pointing to an object that was allocated by a different object, in which case it’s the responsibility of the object that originated the pointer’s address, also to destruct the object it points to… This can lead to issues because, if the object that created the object being deleted does so, the other object will still hold an address, which does not get updated (at least, using plain-old C++ pointers, not, smart-pointers). And then, such a copied address might erroneously be used again, creating nasty error messages and crashes.

The problem with scenario (2) above is, that even though the pointer will get removed eventually, during program execution, the object that it points to, will remain by default, unless we call ‘delete’ on the pointer, in which case the destructor will be called on the object pointed to, and then, the space the object occupied is deallocated. There are finer points to how all this should be done, which are taught in C++ programming, and which I will not get into here. But a point which I want to make in this posting is that, when using certain GUI libraries, including Qt5, the programmer is creating many C++ objects, including widgets, layout managers, labels, QString objects, and eventually also, brief message-boxes…

The programming style encourages sloppy programming, in which not all objects that have been created, are also destructed and deallocated eventually. Admittedly, I have also fallen victim to this, in recent exercises I assigned myself, outside any formal learning environment. And of course, always conscious of the possibility that I could be making mistakes, I have found several.

The lessons I was given formally taught us, to be so thorough in deallocating, that we should even do so when our program quits. This is good form. But, when creating my Qt5 projects, I have not been doing this. Instead, what I’ve been doing, is to distinguish between two types of memory leaks:

  1. Objects that are not deleted when the program quits, meaning that my main application window possesses a destructor which does nothing,
  2. Objects that will need to be deleted, because they were members (properties) of other objects, which might be specialized windows of my application, or which might otherwise be created and deleted many times, during one execution of the application.

 

(Updated 9/03/2020, 14h20… )

Continue reading The ubiquity of memory leaks in GUI applications.

Using QWidgetActions to place arbitrary widgets inside command-menus.

Again, on the subject of finding unusual ways to use the Qt GUI Library, to solve certain atypical problems that can exist in the design of applications. What a programmer might want to do, beyond giving his application command-menus, that fire Signals, which are received by Slots, which in turn evoke the capabilities of his or her program. The programmer may feel that he needs an entry in this command-menu to have an unusual appearance, such as, to consist of blue text, with a background that goes from being neutral to being yellow, when this entry is hovered over with the mouse…

Well, Qt has a special base-class for that sort of thing, which is called ‘QWidgetAction’. The idea behind it is, that it inherits the ‘QAction’ class, that would normally be added to the menus, but in such a way, that it additionally connects with a ‘QLabel’ object, which in turn can be given the most striking appearances, including rich text in the form of HTML.

This is what the result looks like:

Screenshot_20200821_021223_e

The ‘Reset Program’ command is different in appearance, from the other menu entries.

This is the code that was required, to make it happen:

The file ‘menubar.h‘ –

 


#ifndef MENUBAR_H
#define MENUBAR_H

#include "mainwindow.h"

class SimpleMenu : public QWidget
{

public:
    SimpleMenu(MainWindow *parent = 0);

};

class HoverWidget : public QLabel
{
public:
    HoverWidget(QWidget *parent);

    void enterEvent(QEvent * event);
    void leaveEvent(QEvent * event);
};

#endif // MENUBAR_H


 

The file ‘menubar.cpp‘ –

 


#include "menubar.h"
#include "mainwindow.h"
#include <QApplication>
#include <QMenu>
#include <QMenuBar>
#include <QWidgetAction>

SimpleMenu::SimpleMenu(MainWindow *parent)
    : QWidget(parent)
{

    QAction *quit = new QAction("&Quit", this);
    quit->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_Q));

//    QAction *reset_window = new QAction(this);
//    reset_window->setText("Re&set Program!");
//    reset_window->setShortcut(Qt::CTRL + Qt::Key_0);

    QAction *zoom_in = new QAction("Zoom I&n", this);
    QAction *zoom_out = new QAction("Zoom Ou&t", this);

    zoom_in->setShortcut(Qt::CTRL + Qt::Key_Plus);
    zoom_out->setShortcut(Qt::CTRL + Qt::Key_Minus);

    QMenuBar *toplev = new QMenuBar(parent);

    QMenu *file;
    file = toplev->addMenu("&File");
    file->addAction(zoom_in);
    file->addAction(zoom_out);
    file->addSeparator();
    file->addAction(quit);

    QMenu *help;
    help = toplev->addMenu("&Help");

    HoverWidget *reset_window_label = new HoverWidget(help);
    reset_window_label->setText("Reset Program            Ctrl+0");
    reset_window_label->setStyleSheet("QLabel {color: blue; margin: 4px}");
    QWidgetAction *reset_window = new QWidgetAction(this);
    reset_window->setDefaultWidget(reset_window_label);
    reset_window->setShortcut(Qt::CTRL + Qt::Key_0);

    help->addAction(reset_window);

    //  Qt5 Semantics for Signals sent to Slots...

    connect(quit, &QAction::triggered, qApp, &QApplication::quit);

    connect(reset_window, &QAction::triggered, parent, &MainWindow::resetQ);
    connect(zoom_in, &QAction::triggered, parent, &MainWindow::zoom_in_do);
    connect(zoom_out, &QAction::triggered, parent, &MainWindow::zoom_out_do);

}

HoverWidget::HoverWidget(QWidget *parent) :
    QLabel(parent)
{
    setAttribute(Qt::WA_Hover, true);
}

void HoverWidget::enterEvent(QEvent *event)
{
    setStyleSheet("QLabel {color: blue; background-color: yellow; margin: 4px}");
    QLabel::enterEvent(event);
}

void HoverWidget::leaveEvent(QEvent *event)
{
    setStyleSheet("QLabel {color: blue; margin: 4px}");
    QLabel::leaveEvent(event);
}

 

The exercise in which I tested this feature can be found at the following URL within my own site:

https://dirkmittler.homeip.net/binaries/

And, the relevant compressed archives are named ‘Creator_Test3.tar.gz‘ and ‘Creator_Test3.zip‘.

(This is a link to the previous exercise.)

 

(Update 8/22/2020, 17h40: )

Continue reading Using QWidgetActions to place arbitrary widgets inside command-menus.

Basic Qt5 Slots, Signals and Menus Example

In case the reader is an aspiring programmer, but yet a hobbyist, one of the facts which he or she will already know is that, in order to design applications which have a Graphical User Interface, some predefined GUI Library is commonly used, and one example of a GUI Library which can be used is Qt 5. Therefore, in order to become proficient at using this library, like me, the reader might want a working example of:

  • Signals and Slots – The way in which Qt connects user-actions on the GUI, to actions which should be triggered from the actual program,
  • The use of the ‘QLabel’ class to display an image instead of more-common text,
  • The design of a very basic command-menu and a keyboard shortcut,
  • A QRC Resource Script.

Even though this example was created with ‘Qt Creator’ and Qt version 5.7, one of the main features of Qt Creator, its GUI Layout Designer, has been cut from the project, so that the means by which such mechanisms can be set up entirely via code, can be explored better. Also, while Qt5 maintains backwards-compatibility with Qt4 -style Signals and Slots, that are based on macros, this project makes use of the newer Qt5 semantics, that are based on function pointers, for the sake of favouring new features over old.

I can say that on my Debian 9 / Stretch computer, the example works. However, the Qt Library is designed to be cross-platform, and so the example should also work under Windows. What some people have suggested is that, in order to get such code to work under OS/X, ‘ccmake’ should be used with the ‘Unix Makefiles’ generator. This will assume that ‘XCode’ is already installed. (:1)

The Link where the compressed files, containing only source code, can be found (along some other compressed files that also contain precompiled binaries, belonging to other projects) is here:

https://dirkmittler.homeip.net/binaries/

In that Gopher-Hole, the files of interest would be ‘Creator_Test2.tar.gz‘ or ‘Creator_Test2.zip‘.

Continue reading Basic Qt5 Slots, Signals and Menus Example