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:

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

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

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.

Bundling AppImages with Themes.

One of the projects which I have been undertaking in recent weeks has been, to teach myself GUI programming using the Qt5 GUI Library, of which I have version 5.7.1 installed on a good, tower computer, along with the IDE “Qt Creator”. What can be observed about this already is, that under Debian 9 / Stretch, which is a specific build of Linux, in addition to just a few packages, it’s really necessary to install many additional packages, before one is ready to develop Qt Applications, because of the way Debian breaks the facility into many smaller packages. Hypothetically, if a person was using the Windows, Qt SDK, then he or she would have many of the resources all in one package.

Beyond just teaching myself the basics of how to design GUIs with this, I’ve also explored what the best way is, to deploy the resulting applications, so that other people – technically, my users – may run them. This can be tricky because, with Qt especially, libraries tend to be incompatible, due to even minor version differences. So, an approach which can be taken is, to bundle the main libraries required into an AppImage, such that, when the developer has compiled everything, the resulting AppImage – a binary – is much more likely actually to run, on different versions of Linux specifically.

The tool which I’ve been using, to turn my compiled binaries into AppImage’s, is called ‘linuxdeployqt‘, and is not available in the Debian / Stretch repositories. However, it does run under …Stretch.

But a developer may have questions that go beyond just this basic capability, such as, what he or she can do, so that the application will have a predictable appearance – a “Style” or “Theme” – on the end-user’s Linux computer. And essentially, I can think of two ways to approach that question: The ‘official but slightly quirky way’, and ‘a dirty fix, that seems to get used often’…

The official, but slightly quirky way:

Within the AppImage, there will be a ‘plugins’ directory, within which there will be a ‘platformthemes’ as well as a ‘styles’ subdirectory. It’s important to note, that these subdirectories serve officially different purposes:

  • The ‘platformthemes’ subdirectory will contain plugins, that allow the application to connect with whatever theme engine the end-user’s computer has. Its plugins need to match libraries that the eventual user has, determining his desktop theme, And
  • The ‘styles’ subdirectory may contain plugins, which the end-user does not have installed, but were usually compiled by upstream developers, to make use of one specific platform-engine each.

Thus, what I had in these directories, for better or worse, was as shown:

 

dirk@Phosphene:~/Programs/build-Dirk_Roots_GUI_1-Desktop-Release/plugins/platformthemes$ ls
KDEPlasmaPlatformTheme.so  libqgtk2.so  libqgtk3.so
dirk@Phosphene:~/Programs/build-Dirk_Roots_GUI_1-Desktop-Release/plugins/platformthemes$ 


dirk@Phosphene:~/Programs/build-Dirk_Roots_GUI_1-Desktop-Release/plugins/styles$ ls
breeze.so  libqgtk2style.so
dirk@Phosphene:~/Programs/build-Dirk_Roots_GUI_1-Desktop-Release/plugins/styles$ 

 

The reader may already get, that this was a somewhat amateurish way, to satisfy themes on the end-user’s machine. But in reality, what this set of contents, of the AppImage, does rather well is, to make sure that the 3 main theme engines on an end-user’s computer are recognized:

  1. Gtk2,
  2. Gtk3,
  3. Plasma 5.

And, if the application tries to make no attempts to set its own theme or style, it will most probably run with the same theme, that the end-user has selected for his desktop. But, what the point of this posting really is, is to give a hint to the reader, as to how his AppImage could set its own theme eventually. And so, according to what I just cited above, my application could choose to select “Breeze” as the Style with which to display itself, or “Gtk2″. But, here is where the official way gets undermined, at least as the state of the art was, with v5.7.1 of Qt:

  • ‘Breeze’ can only be set (by the application), if the end-user’s machine is running Plasma 5 (:1), And
  • ‘Gtk2′ can only be set (by the application), if the end-user’s machine supports Gtk2 themes, which many Plasma 5 computers have the additional packages installed, to do.

What this means is that, even though I could try to create a predictable experience for the end-user, what the end-user will see can still vary, depending on what, exactly, his platform is. And beyond that, even though I could set the ‘Gtk2′ Style with better reliability in the outcome, I could also just think, that the classical, ‘Gtk2′ style is a boring style, not worthy of my application. Yet, in this situation, I can only select the “Breeze” theme from within my application successfully, if the end-user is based on Plasma 5. If the end-user is not, then my application’s attempt to set “Breeze” will actually cause Qt v5.7.1 to choose the “Fusion” theme, that Qt5 always supports, that might look okay, but that is not “Breeze”…

 

So, what other options does the application developer have?

(Updated 9/12/2020, 18h15… )

Continue reading Bundling AppImages with Themes.

It’s perfectly possible to run AppImages from within Crostini.

One of the assets which I have, is an Asus Chromebook, that has modest specifications (including mere 32GB of storage), but on which I did activate the Debian / Stretch flavour of Linux. (:1)  I should also mention that this Chromebook has the Intel Celeron N3350 CPU, which runs the x86_64 instruction set. This latter detail is of some importance, as full compatibility with Linux will not be realized without it. Admittedly, the subset of Debian / Stretch packages that have been cross-compiled to ARM CPU binaries is limited, and what I’m about to describe in this posting will not work at all, on ARM CPUs (that were also the more-common CPUs for use with Android).

The virtual machine that runs Linux inside ChromeOS is also called “Crostini”.

One of the limitations which I’ve heard about Crostini is, that one cannot perform most loop-mounts in root mode. For that reason, there might be some misgivings about being able to run AppImage’s, because those require a user-space mount of a ‘SquashFS’ file system, and also require the existence of a kernel module to do so.

Therefore, I am most happy to report, that on my Linux setup, and with up-to-date Chrome 85…, I am able to run AppImage’s after all, that were meant for Linux, and for the 64-bit, Intel / AMD CPU family.

As an example, I was well-able to download the Kdenlive video editor, in the form of the Linux AppImage, and to get it to run under ChromeOS. I find that often, the video editing features available from Google Play / Android apps are way too limiting.

Thus, I am finding new ways to enjoy my Chromebook and its Linux subsystem. I would warn people though, that, before running AppImage’s, they install a somewhat complete set of Linux applications and libraries.


 

(Updated 4/04/2021, 20h10… )

Continue reading It’s perfectly possible to run AppImages from within Crostini.