A Small Touch-Up to one of my Projects

One of the things which I did in the past was, to write a C++, Qt5 application, which was meant as a test, of how to incorporate certain GUI elements into a program, those elements extending as far as, how to force the program to display with my own desktop theme, even on target computers that do not have this theme set or installed.

I was so focused on that aspect of the project, that I had overlooked a simpler aspect of it: What would happen if the user decided to resize the window. The initial window size is 850×720, and resizing, so far, was ugly. But, according to tonight’s update, the resizing behaviour has been made much nicer. (:1)

The relevant files can be found in the following directory on my site:


The files are the ones that begin with ‘Creator_Test6...‘ .

There is also a compiled AppImage that will run on Linuxes with at least ‘CXXABI_1.3.9′ (equivalent to Debian 9 / Stretch), but no binary to run under Windows. Sorry for that last omission. However, readers who have the Qt SDK installed, should be able to compile under Windows as well. What needs to be done, when Qt projects are being recompiled with another computer’s SDK, is, that the file ‘Creator_Test6.pro.user‘, typically, needs to be deleted, as it contains details specific to one version of the SDK. Because of this, the Project Configuration – i.e., the Toolkits that are to become compile targets – will then also need to be redefined by any interested power-user.


There’s a small observation to add about this software project. The concept that it should display in its own desktop theme, only works fully, when running the AppImage under Linux. That is because I linked the Theme Engines and Styles in, using the command-line tool ‘linuxdeployqt‘. Those were binary plug-ins, that I do not even possess the source-code for. Hence, if the reader custom-compiles the same project, they will find that those plug-ins have not been compiled, and that for this reason, the app will display with the local Style at best.

In reality, there are two separate settings:

  1. QIcon::setThemeSearchPaths(":/res/icons");
  2. QApplication::setStyle("Breeze");

Out of those, the first should even work if the reader custom-compiles, but the second should not.


(Updated 8/02/2021, 7h45… )

Continue reading A Small Touch-Up to one of my Projects

Improvement in my ability to compile code.

One of my practices on this blog has been, to compile certain programs for use either under Linux or Windows, depending on which compiled binary gets used by my reader, to sign any Windows .EXE Files, but only to be able to generate such Windows executables, if they did not have a GUI – i.e., if they were meant to be used in text-mode only, from a Windows command-prompt.

One reason for this has been, the fact that I was teaching myself the Qt5 GUI library, which is cross-platform, but which requires software beyond Visual Studio to compile on the Windows platform I’ve been using, just for such projects.

Ideally, I’d be able to write a Qt5 application once, and then compile it separately, for use under Linux or Windows, and on top of that, to put my code signature on the Windows executable.

Well, I’ve gotten closer to this objective, by means of brute force. I’ve installed the Qt SDK for Windows, in a way that parallels my installation of Qt development packages under Linux. I am able to transfer the source code, and then compile it on the other platform.

Once again, the URL at which my list of potential binaries resides, is:


And the 4 new additions, which did not previously have Windows executables within, are:

  • ‘Creator_Test3.tar.gz’
  • ‘Creator_Test3.zip’
  • ‘Dirk_Roots_GUI_1.tar.gz’
  • ‘Dirk_Roots_GUI_1.zip’





How to know, whether our Qt 5 C++ projects make use of dynamically-loaded plug-ins.

I have used Qt Creator, with Qt version 5.7.1, to create some simplistic GUI applications as exercises. And then, I used the tool named ‘linuxdeployqt’, in order to bundle those (compiled) applications into AppImage’s, which should, in principle, run on other users’ Linux computers. (:4)  But, when using these tools, a question arose in my head, which I was also able to deduce the answer to quickly, in the form of, ‘Why does linuxdeployqt exist separately from linuxdeploy? Why does the developer need a tool which bundles library files, but which exists separately, just for C++ Qt applications? Obviously, some AppImages are not even based on that GUI library.’

And the short answer to that question is, ‘Because unlike some other application frameworks, Qt is based heavily on plug-ins, which none of my simpler exercises required explicitly.’ And, what’s so special about plug-ins? Aside from the fact that they extend the features of the application framework, plug-ins have as special property, that the application can decide to load them at run-time, and not with static awareness, at build-time. What this means is that a tool such as ‘linuxdeploy’ will scan the executable, which has been built by whichever compiler and/or IDE the developer used, will find that this executable is linked to certain shared libraries (with static awareness), but will not recognize some of the libraries which that executable needs to run, just because those are plug-ins, which the application will only decide to load at run-time.

Hence, to get the full benefit of using ‘linuxdeployqt’, the developer ‘wants to’ end up in a situation similar to the situation described Here. Granted, the person in question had run in to a bug, but his usage of the feature was correct.

This usage differs from my earlier usage, in that I never fed any ‘extra-plugins’ list to ‘linuxdeployqt’, yet, when I used the tool for creating the AppImage, my (project’s) plug-ins folder was populated with certain libraries, that were also plug-ins. And so, a legitimate question which an aspiring developer could ask would be, ‘How do I know, whether my Qt application loads plug-ins dynamically at run-time, so that I’ll know, whether I also need to specify those when bundling my AppImage?’ After all, it would seem that in certain cases, the plug-ins are in fact loaded with static awareness, which means that ‘linuxdeployqt’ can just recognize that the application is loading them, without the developer having had to make any special declaration of the fact.

One possible answer to that question might be ‘Test the AppImage, and see if it runs.’ But one problem with that answer would be, that if the executable cannot find certain plug-ins as bundled with the AppImage, the danger exists, that it may find those on the Host Machine, and that the application will end up running on some hosts, but not on other hosts, depending on what version of Qt the recipient has installed, and, depending on which plug-ins that recipient also has installed. And so, a better way must exist, for the developer to know the answer to this question.

(Updated 4/05/2021, 8h55… )

Continue reading How to know, whether our Qt 5 C++ projects make use of dynamically-loaded plug-ins.

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:


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