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.

Observations, on how to insert Unicode and Emojis into text, using a KDE 4 / Plasma 5.8 -based Linux computer.

One of the earliest ‘inventions’ on the Internet, were ‘Smilies’, which were just typed in to emails, and which, when viewed as text, evoked the perception of whichever face they represented. But, graphical user interfaces – GUIs – replaced simple text even in the 1990s, and the first, natural thing which developers coded-in to email clients was, the ability to convert typed, text-based smilies, into actual images, flowed with the text. Also, simple colon-parenthesis sequences were replaced with other, more varied sequences, which could be converted by some email clients into fancier images, than simply, smiling faces.

Actually, the evolution of the early Internet was slightly more complex than that, and I have even forgotten some of the real terms that were used to describe that History.

But there is an even more recent shift in the language of the Internet, which creates a distinction between Smilies, and ‘Emojis’. In this context, even many ‘Emoticons’ were really just smilies. Emojis distinguish themselves, in that these pictograms are represented as part of text in the form of Unicode values, of which there is such a large supply, that some Unicode values represent these pictograms, instead of always representing characters of the Earth’s many languages, including Chinese, Korean, Cyrillic, etc. What some readers might ask next could be, ‘Traditionally, text was encoded as 7-bit or 8-bit ASCII, how can 16-bit or 32-bit Unicode characters simply be inserted into that?’ And the short answer is, through either UTF-8 or UTF-16 Encoding. Hence, in a body of text that mainly consists of 8-bit codes, half of which are not normally used, sequences of bytes can be encoded, which can be recognized as special, because their 8-bit values do not correspond to valid ASCII characters, and their sequences complete a Unicode character.

One fact which is good to know about these Emojis is, that they are often proprietary, which means that they are often either the intellectual property of an IT company, or part of an Open-Source project. But the actual aspect of that which can be proprietary is, the way in which Unicode values are rendered to images.

What that means is that, for example, I can put the following code into my blog: 🤐 . That is also referred to as Unicode character ‘U+1F910′. Its length extends beyond 16 bits by 1 bit, and the next 4, most-significant bits are all 1’s, as expressed by the hexadecimal digit ‘F’. It’s supposed to be a pictogram of a deceased entity, as if that were stated correctly by a head which has had certain features crossed out. But for my blog, the use of such a code can be a hazard, because it will not display equally on Android devices, as it displays on iOS devices. And, on certain Linux computers, it might not be rendered at all, instead just resulting in a famous rectangle that seems to have dots or numbers inside it. This latter result will form, when the client-program could not find the correct Font, to convert this code into an image. (:3)

Those fonts are what’s proprietary. And, they also provide some consistency in style, between Android devices, OR between iOS devices, OR between Windows devices, etc.

Well, I began this posting by musing about the early days of the Internet. During those days, some users – myself included 😊  – did some things which were truly foolish, and which included, to put background images into our HTML-composed emails, and, to decorate documents with (8-bit) dingbat fonts, just because it was fun to pass certain fancier documents around, than POT. I don’t think there is really anything wrong with potential readers, who still put background images into their emails. What I mean is that many of my contacts today, prefer emails which are not even HTML.

This earlier practice, of using dingbat fonts etc., tended to play favourably into the hands of the tech giants, because the resulting documents could only be viewed by certain applications. And so today, I needed to ask myself the question, of how often the use of Emojis can actually result in a document, which the recipient cannot read. And my conclusion is that today, such an indecipherable outcome is actually rare. So, how I would put a long story short is to say, that Commercialism is back, riding on the desire of younger people to put more-interesting content into their messages, and perhaps, without some of the younger people being aware that when they put Emojis, they are including themselves as the software-disciples of one larger group or another. But that larger group mainly seems to be drawing its profits, from the ability of certain software to insert the images, rather than, the ability of only certain software to render them at the receiving end (at all). Everybody knows that, even though the input methods on our smart-phones don’t lead to massively good prose, they almost always offer a rich supply of Smilies, plus Emojis, all displayed to the sender using his or her own font, but later displayed to the recipient, using a potentially different font.

The way Linux computers can be given such fonts, is through the installation of packages such as ‘fonts-symbola’ and ‘ttf-ancient-fonts’, or of ‘fonts-noto‘… The main drawback of the open-source ‘Symbola’ font, for example, is simply, that it often gives a more boring depiction of the same Unicode character, than the depiction which the true Colour Noto Font from Google would give.

One interesting way in which Linux users are already in on the party is, in the fact that actual Web-browsers are usually set to download fonts as they are needed, even under Linux, for the display of Web-pages. Yet, email clients do not fall into that category of applications, and whether they render Emojis depends on whether these font packages are installed.

Hence, if the ability to send Emojis from a Linux computer is where it’s at, then this is going to be the subject of the rest of my posting. I can put two and two together, you know…

(Updated 7/31/2020, 15h10… )

Continue reading Observations, on how to insert Unicode and Emojis into text, using a KDE 4 / Plasma 5.8 -based Linux computer.