One project which I have been posting about has been, my ongoing effort to teach myself how to use the Qt5 GUI Library, which professional programmers do use in order to design Graphical User Interfaces – GUIs – for applications / programs. In fact, in a preceding posting, I wrote that I had discovered a deliberately unusual way to use one of the object classes in Qt 5.7.1, so that a ‘QImage’ object could be rendered to the screen of a computer, without first having to be transformed into a ‘QPixmap’ object. The ordinary thing to do would be, to transform it thus, first.
That trick can increase performance if two situations are met:
- The graphical information could have started out as a bitmapped image, And
- That image could have been unusually large, so that to have to buffer the entire image in its uncompressed form several times, could pose a considerable drain on the amount of memory that even modern computers should part with.
But, when designing GUIs, the starting point of the graphical information can be, simulated brush-strokes, with a simulated ‘QBrush’ and ‘QPen’, that are orchestrated by a programmer to give logical meaning to his GUI (beyond just adding the predefined widgets to it). In that case, the trick which I just wrote about will not gain anything over what I am about to describe.
When the ‘QPainter’ object and session are initialized, their target can be a ‘QPixmap’ object, and, after a sequence of painting instructions has finished, it can be assigned to a ‘QLabel’ widget once, by way of the ‘.setPixmap()’ function, thus resulting in a custom widget. Much buffering takes place, and, if the code has been written correctly, the graphic appears on the screen. The following is the graphic which my latest exercise generated:
Admittedly, this does not correspond to the GUI of any real software. But hypothetically, it just as well might. In fact, ‘A Chess-Board’ is just as easy to construct, using the same methodology. Only, actually programming the computer to play Chess is a little harder.
The fact that I was able to post this graphic was partially due, to the added ability the Qt5 Libraries have, to Save a ‘QPixmap’ object, or a ‘QImage’ object, directly to the hard drive, using a simple, straightforward API, and to the format of a PNG File. That task is also achieved in the code sample I am about to link to.
The real caveat here is, Not to try doing funny stuff with the internal ‘.pixmap()’ pointer that belongs to the ‘QLabel’ object, because even though it can be done, writing to that internal property does not offer much in the way of performance improvements, when the goal is to design most GUIs.
(Updated 8/21/2020, 21h25… )
(As of 8/18/2020, 15h20: )
The function call I just named returns a constant pointer, to a ‘QPixmap’ object. By using C semantics in spite of a C++ program being written, such a pointer can just be statically cast to a non-constant pointer, to the same object. At that point, the object can be made the target of the ‘QPainter’ sequence, and graphics which are drawn, will get displayed slightly faster, than graphics which needed to be assigned to the ‘QLabel’ object by way of the ‘.setPixmap()’ function.
Here is why that approach does not gain much in the end:
As soon as the window is resized, the ‘QLabel’ object needs to be given a whole new ‘QPixmap’ object. At the very least, an initialized ‘QPixmap’ needs to be fed to the ‘.setPixmap()’ function in its entire length, for every increment by which the application window is resized. The ‘.resize()’ function that all ‘QWidgets’ have, only works on Text in the case of the ‘QLabel’ sub-class. Thus, initial speed improvements can just evaporate, because resizing the window could become the main reason its graphics need to be updated, not, more and more paths being painted to it.
Thus, the most efficient sequence that I can think of in this case is:
- Leave the fact until later, that the ‘QPixmap’ needs to be displayed,
- Use ‘QPainter’ to paint to said object,
- Feed the finished object to the ‘QLabel’ widget, as part of each update of the GUI,
- The new graphics are displayed.
The source code for my latest experiment can be found at this part of my site:
And, the relevant files are named ‘
Creator_Test5.tar.gz‘ and ‘
There are no executables; the files are only useful to readers who would try to compile them.
There is more that I should comment, about the use of ‘QPixmap’ objects with ‘QLabels’. This is the format of a graphic, which Qt can use in the most different places, not just as one possible payload of a ‘QLabel’. This latter type of widget has as its distinguishing features that:
- It allows No user interaction, only displays the Text or Graphics, but within the pattern of a Layout Manager, (:1)
- It will even play animations in the form of ‘QMovie’ objects,
- It’s especially versatile in doing what was just described.
The Qt Libraries also offer the ‘QPushButton’ object class, which can be clicked on by the user, and which can switch between displaying different Icons, depending on their State and Mode. And again, the ‘QIcon’ objects can be loaded to the ‘QPushButton’ objects, revealing ‘QPixmap’ images.
Therefore, if a programmer has in fact mastered creating arbitrary ‘QPixmap’ objects (images), let’s say, by using ‘QPainter’, then he or she is only one small step away from truly creating custom widgets.
In my exercises I have not played with ‘QIcon’ objects yet, because I was focussed on how to manipulate ‘QPixmap’ objects, and any other possible targets of ‘QPainter’.
(Update 8/18/2020, 17h10: )
Even though the user of an application cannot interact with labels directly, as their name implies, they can be arranged in a parallel pattern with check-boxes or radio-buttons. The check-boxes themselves then generate Signals when checked, signals that get sent to the application and that trigger the application to do something. The application’s features will be activated through Slots, that receive the Signals. But it would be the ability of the user to recognize the labels next to those check-boxes, that make it easy for him or her to know which check-boxes he needs to check or uncheck.
There could be many readers who already understand this, but there could just as easily be readers who passively think, that the labels next to check-boxes are one with the check-boxes. AFAIK,
they are separate widgets, coordinated through the use of Layout managers.
(Update 8/21/2020, 21h25: )
Actually, it turns out that I was mistaken. With the Qt Libraries, every time the application programmer places a check-box, he also places the label to go with it, in the form of a text string, as well as an optional icon. Live and learn. Also, those text strings are allowed to have mnemonic letters, denoted the same way as they are in menu-entries.